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Preface 


The  AFIT  School  of  Engineering  installed,  in  April  1980,  a 
Data  General  ECLIPSE  S/250  and  NOVA  2/10  computer  system  to 
serve  as  the  foundation  for  a  digital  signal  processing 
facility.  To  expand  the  processing  capability  of  the  new 
facility,  a  means  to  interface  the  NOVA/ECLIPSE  computers  with 
the  locally  accessible  Aeronautical  Systems  Division  CDC  CYBER 
computer  system  was  desired.  I  undertook  this  project  and 
constructed  a  general  purpose  command  language  that  could  be 
used  in  varied  applications. 

I  heartily  thank  Captain  Larry  Kizer,  my  thesis  advisor, 
for  his  steady  encouragement  and  sure  support.  I  also  thank  Lt 
Colonel  James  Rutledge  and  Professor  Gary  Lamont  for  their 
support.  On  several  occasions,  Mr.  Hurst  D.  Carlstvom  of  the 
Avionics  Laboratory  provided  invaluable  and  timely  assistance. 
His  experience  and  knowledge  of  the  NOVA/ECLIPSE  computers  were 
eagerly  exploited.  Finally,  I  thank  my  wife  Betty  and  my  two 
children  for  their  patience,  sacrifice,  and  love.  They  have 
been  a  source  of  strength  and  sustenance  throughout  this 
project.  I  also  reverently  give  thanks  and  praise  to  my  Lord 
and  Savior  Jesus  Christ  for  His  providence  and  counsel  through 
it  all . 
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Abstract 

Two  computer  programs  were  developed  and  implemented  to 
enable  intercommunication  between  a  Data  General  NOVA/ECLIPSE 
computer  system  and  another  modem  linked  computer  system.  One 
program,  called  TTERMOP,  allows  a  user  to  sit  at  a  NOVA 
terminal  and  interact  with  a  connected  system  in  a  transparent 
mode.  The  other  program,  called  MONITOR,  is  a  command  language 
interpreter  that  examines  and  executes  instructions  contained 
within  an  action  file.  An  action  file,  consisting  of 
instruction  strings  ar.d  associated  control  parameters,  is 
designed  to  be  dependent  upon  a  connected  system  with  regard  to 
contents,  yet  independent  of  such  a  connected  system  with  regard 
to  structure  and  format.  The  interpreter  is  written  in  FORTRAN 
IV  with  FORTRAN  and  assembly  language  modules.  Actual 
implementation  of  the  programs  is  accomplished  between  the 
NOVA/ECLIPSE  and  the  Aeronautical  Systems  Division  Control  Data 
CYBER  computer  system.  ASCII  data  files  between  20  and  35,000 
bytes  have  been  transferred  between  the  two  interconnected 
systems,  each  transfer  initiated  by  a  single  string  command 
acceptable  to  the  interpreter  and  compatible  with  a  tailored 
action  file  for  the  CYBER  system.  The  programs  were  designed  to 
be  flexible  enough  for  use  with  several  different  connected 
systems,  and  general  enough  to  be  hosted  on  a  system  other  than 
the  NOVA/ ECLIPSE .  However,  no  attempt  is  made  to  implement  the 
programs  outside  of  the  NOVA/ECLIPSE  -  CYBER  environment. 
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CONSTRUCTION  OF  A  GENERAL  PURPOSE  COMMAND  LANGUAGE 
FOR  USE  IN  COMPUTER  TO  COMPUTER  DIALOG 


I .  Introduction 


Background 

Under  sponsorship  of  the  United  States  Air  Force  Electronic 
Systems  Division  and  the  United  States  Air  Force  Aerospace 
Medical  Research  Laboratory,  the  Air  Force  Institute  of 
Technology  (AFIT)  Electrical  Engineering  (EE)  department  is 
undertaking  research  in  digital  signal  processing,  specifically 
digital  speech  processing  and  digital  image  processing.  A  Data 
General  Corporation  (DGC)  NOVA  2/10  computer,  a  DGC  ECLIPSE 
S/250  computer,  and  associated  peripheral  equipment  are  being 
combined  and  integrated  to  form  the  signal  processing  facility. 

To  expand  the  local  processing  capability  of  the  facility, 
the  EE  department  proposed  to  interface  the  DGC  computers  with 
the  larger  and  more  sophisticated  Control  Data  Corporation  (CDC) 
CYBER  computer  system,  which  is  operated  by  the  United  States 
Air  Force  Aeronautical  Systems  Division  (ASD)  and  which  provides 
support  to  AFIT.  (Both  AFIT  and  ASD  are  located  at 
Wr ight-Patter son  AFB,  Ohio.)  Interfacing  the  two  systems  would 
allow  intercommunication  between  the  two  systems,  wherein  the 
advantage  of  each  system's  features  could  be  utilized.  The  CDC 
CYBER  system,  consisting  of  a  dual  CYBER  175  and  a  CYBER  750, 
could  readily  provide  the  "number  crunching"  and  file  repository 
required  to  help  analyze  signals.  The  NOVA/ECLIPSE  system  could 
then  be  devoted  to  other  signal  processing  functions,  such  as 


analog  to  digital/digital  to  analog  conversions.  Furthermore, 
though  the  systems  would  be  capable  of  intercommunication,  the 
failure  of  one  of  the  two  systems  would  not  mean  the  failure  of 
the  other  system.  Thus,  each  system  could  stand  alone  —  or  be 
interconnected  for  supplementary  processing  power. 

Expanding  the  capability  of  the  signal  processing  facility 
by  interconnection  to  the  CYBER  computer  system  may  not  be  the 


only  expansion  possible. 

Many  other 

computer  facilities 

are 

available 

in  the  AFIT 

School  of 

Engineering,  as  well 

as 

throughout 

Wr ight-Patter 

con  AFB. 

The  EE  department 

also 

proposed,  therefore,  that  the  method  of  interfacing  the  local 
NOVA/ECLIPSE  computers  be  flexible  enough  to  be  used  with 
systems  other  than  the  CYBER,  and  that  the  interfacing  be 
general  enough  to  be  applied  by  separate  and  distinct  systems, 
if  possible. 

Problem  Statement 

Interfacing  the  NOVA/ECLIPSE  computers  to  the  CYBER  system 
or  any  other  system  may  be  viewed  in  two  parts.  One  part  of  the 
interfacing  would  be  to  connect  the  NOVA/ ECLIPSE  computers  to 
the  CYBER  system  just  as  any  other  peripheral  would  be  connected 
or  appear  to  be  connected.  In  this  case,  the  CYBER  system  would 
treat  the  NOVA/ ECLIPSE  computers  as  one  of  its  many  terminals, 
not  recognizing  that  it  is  a  complete  computer  system.  This 
type  of  interface  is  not  complex,  and  involves  accessing  an 
input  and  output  port  on  the  NOVA  or  ECLIPSE  via  a  data  line  of 
the  local  telephone  system  to  the  CYBER  system.  Connection  to 


the  CYBER  system  would  be  accomplished  in  the  same  fashion  as 
other  terminals  are  connected.  A  user  would  call  a  prescribed 
telephone  number  and  couple  the  telephone  line  to  the  data  rt 
line  via  a  standard  modem.  After  connection,  a  resident 
software  program  designed  for  the  purpose  would  be  called  into 
execution  to  control  input  and  output  transfers.  Any  local 
terminal  of  the  NOVA  or  ECLIPSE,  whichever  owned  the  selected 
data  port,  would  appear  transparently  as  a  terminal  directly 
connected  to  the  CYBER. 

The  limitations  of  this  first  part  are  the  same  as  those 
limitations  any  typical  terminal  has  when  connected  to  the  CYBER 
system.  First  of  all,  the  language  for  communication  must  be 
that  of  the  "host"  system,  and  in  this  instance,  it  is  the  CYBER 
operating  system.  Presently,  the  CYBER  operating  system 
language  is  called  NOS/BE  (Network  Operating  System/Batch 
Environment).  The  users  of  the  signal  processing  facility 
desire  a  language  of  intercommunication  other  than  NOS/BE,  that 
simplifies  intercommunication  and  reduces  the  complexity  of  user 
access.  Furthermore,  they  desire  that  such  a  language  be 
understandable  and  portable,  i.e.,  that  may  be  used  or.  more 
than  one  machine  for  the  same  purpose.  A  second  and  even 
greater  limitation  of  the  transparent  terminal  interface  is  that 
no  direct  computer  to  computer  dialog  may  take  place.  Under  a 
transparent  terminal  operation,  users  may  access  files  of  the 
CYBER  or  connected  system,  but  cannot  access  local  files.  Also, 
there  is  no  provision  for  the  direct  exchange  of  information, 
such  as  file  transfers,  in  the  transparent  mode. 
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A  second  part  of  interfacing,  then,  would  be  to  connect  the 
NOVA/ECLIPSE  computers  to  the  CYBER  system  or  any  other  system 
such  that  direct  information  exchanges  are  possible.  Within 
this  type  of  environment,  a  user  would  have  access  to  files  on 
the  NOVA/ECLIPSE  and  the  connected  computer  system.  For 
example,  files  from  the  local  system  could  be  transferred  to 
the  connected  system,  executed,  and  returned.  This  type  of 
interfacing  is  significantly  more  complex,  even  though  basic 
connection  techniques  remain  the  same,  since  files  must  be 
identified  and  manipulated.  Because  of  this  need  to  manipulate 
files,  the  software  program  to  control  information  transfers 
becomes  much  more  complex  particularly;  and,  hence,  requires  the 
greater  concentration  of  design  and  development  efforts.  Just 
as  in  the  case  of  the  transparent  mode,  the  users  of  the  signal 
processing  facility  desire  a  language  of  intercommunication  that 
is  understandable  and  portable.  The  language  must  be  simple  and 
provide  a  means  to  issue  commands  both  to  the  local  NOVA/ECLIPSE 
system  and  the  connected  computer  system,  such  as  the  CYBER. 

The  problem,  then,  is  to  develop  a  method  of 
intercommunication  for  use  in  computer  to  computer  dialog.  In 
its  narrower  focus,  the  problem  becomes  one  of  developing  a 
command  language  on  the  DGC  NOVA/ECLIPSE  computer  system  for 
intercommunication  with  the  CDC  CYBER  computer  system. 
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Scope 

An  examination  of  this  problem  involves  researching 
computer  to  computer  interconnections,  with  particular  emphasis 
upon  software  development.  The  compatabil ity  of  operating 
systems  is  briefly  considered,  with  respect  to  the  degree  of 
interconnection  required  at  the  software  level.  The  scope  of 
the  study  also  includes  the  guidelines  that  surround  computer 
to  computer  dialog,  humanized  input  and  output,  and  man-machine 
interfaces.  Though  hardware  considerations  in  the  actual 
implementation  will  be  considered,  the  study  is  not  oriented 
toward  hardware,  nor  will  hardware  be  examined  in  any  depth. 
Further,  the  study  will  not  specifically  be  concerned  with  the 
actual  digital  signal  processing  capabilities  of  the  computer 
system.  Although  the  topics  above  will  be  considered,  the 
6tudy  will  be  devoted  almost  exclusively  to  the  analysis, 
design,  development,  implementation,  testing,  and  review  of 
software  for  interfacing  the  NOVA/ECLIPSE  computers  to  a 
connected  computer  system  (specifically  the  CDC  CYBER)  via  a 
defined  command  language. 

General  Approach  and  Preliminary  Results 

The  first  step  in  constructing  a  command  language  for  use 
on  the  NOVA/ECLIPSE  computers  was  to  search  the  literature  for 
ideas  and  projects  of  a  similar  nature.  Few  articles  were  found 
that  directly  impacted  upon  the  project  at  hand,  but  methods  and 
parameters  for  interfacing  systems  in  general  were  investigated. 
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Other  thesis  efforts  were  reviewed  for  applicability  to  this 
effort,  and  possible  expansion  (Ref  4  and  8).  The  literature 
investigation  was  followed  by  a  period  of  machine 
familiarization,  both  of  the  NOVA/ECLIPSE  and  the  CYBER.  As  the 
NOVA/ECLIPSE  computer  system  was  installed  just  prior  to  the 
full  scale  thesis  effort,  much  time  was  spent  learning  the 
characteristics  of  the  NOVA/ECLIPSE  Real-Time  Disk  Operating 
System  (RDOS).  Initially,  programs  taken  from  operating 
manuals  were  copied  and  executed.  Later,  original  programs  were 
developed  to  duplicate  the  same  actions.  These  initial  efforts 
concentrated  on  assembly  language  facilities,  as  these  were  the 
least  familiar.  The  CYBER  had  been  used  before  and  was  not 
unfamiliar.  Nonetheless,  operating  system  characteristics  were 
examined  in  more  depth. 

Design  of  the  software  to  implement  a  transparent  terminal 
operation  was  next.  It  is  at  this  point  that  the  details  of 
interrupts  and  their  operation  were  examined  and  tested  in 
experiments.  Once  the  transparent  mode  was  workable  from  a 
local  terminal  to  another  local  terminal,  efforts  turned  to 
developing  the  actual  command  language.  Using  top-down  design 
techniques  and  successive  refinement,  individual  modules  were 
developed  as  needed  to  implement  parts  of  the  language.  Early 
on,  the  project  was  divided  into  two  parts,  the  output  from  the 
NOVA/ECLIPSE  and  the  input  to  the  NOVA/ECLIPSE.  Multitasking 
was  used  to  allow  asynchronous  operation  of  these  two  parts.  A 
further  division  was  made  to  the  design.  An  action  file  was 
created  to  actually  contain  command  sequences  as  needed  by  the 
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user.  The  main  program  became  an  interpreter  to  examine  and  act 
upon  this  action  file.  Once  a  working  subset  of  the  final 
product  was  available,  access  to  the  CYBER  system  was  tried. 
The  transparent  mode  software  required  minor  modifications  and 
transitioned  well  to  on-line  execution.  The  transition  of  the 
command  language  itself  was  more  painstaking  and  slow. 

Eventually  the  modules  were  all  developed  and  combined, 
and  then  several  tests  and  trials  were  conducted.  Once  the 
program  was  in  a  reasonably  workable  state,  efforts  began  to 
more  fully  and  comprehensively  document  design,  development, 
implementation,  and  validation  findings.  Finally,  the  project 
was  put  into  written  form  and  a  user's  manual  was  written  to 
instruct  users  in  the  use  of  the  command  language.  Follow-on 
steps  to  this  process  are  recommended  in  the  Conclusion,  Chapter 
V. 

Sequence  of  Presentation 

The  introduction  to  this  project  is  followed  by  an  analysis 
of  the  literature  regarding  man-machine  interfaces  and  command 
language  structures,  an  analysis  of  the  computer  systems 
involved,  the  transparent  terminal  operation  mode,  and  the 
command  language  itself.  The  analyses  are  followed  by  an 
explanation  of  the  development  theory  behind  the  software 
programs.  Once  the  theory  has  been  presented,  the  actual 
development  of  the  software  will  be  discussed,  concentrating 
first  on  a  program  called  TTERMOP  —  the  transparent  terminal 
operation  mode  software,  and  then  a  program  called  MONITOR  — 
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the  actual  command  language  mode  software.  The  discussion  of 
MONITOR  will  include  a  look  at  various  subordinate  modules  and 
routines  that  comprise  MONITOR.  A  section  regarding  validation 
of  the  software  will  follow  the  software  development 
description,  including  its  current  state  and  usefulness.  The 
project  will  then  be  summarized,  pointing  out  several 
possibilities  for  follow-on  work  to  this  thesis. 
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II. 


Detail o  d  Analysis 


An  analysis  of  the  problem  of  interconnecting  the 
NOVA/ECLIPSE  computers  to  another  computer  system  begins  with  a 


look  at  interfacing  in 

general. 

Several 

elements  of 

the 

literature  are  examined 

with  respect 

to 

the 

concepts 

of 

man-machine  interfaces, 

computer 

to 

computer 

dialog, 

and 

command  languages.  This  introductory  look  at  the  problem  is 
followed  by  an  introduction  to  the  NOVA/ECLIPSE  computers  and 
their  primary  features.  Once  the  computers  have  been  described, 
a  closer  look  at  the  methods  of  interfacing  for  the  NOVA/ECLIPSE 
are  mentioned,  particularly  with  regard  to  the  modes  of 
operation  envisioned. 

Man-Machine  Interface 

It  is  becomming  increasingly  important,  though  it  has 
always  been  important,  that  there  be  a  proper  perspective  rfith 
regard  to  the  interaction  of  people  with  computers.  The  past 
emphasis  seems  to  have  been  on  the  usage  of  computers;  the 
newer  emphasis  is  on  the  usage  of  people  (Ref  5:4).  This  change 
in  emphasis  is  an  outgrowth  of  the  volumes  of  information 
computers  generate  and  the  ever  wider  proliferation  of 
computers.  How  do,  or  how  should,  the  two  cooperate?  James 
Martin  states: 

This  difference  in  thinking  talent  —  the  computer 
being  good  for  jltrafast  sequential  logic  and  the 
human  being  capable  of  slow  but  highly  parallel  and 
f  associative  thinking  —  is  the  basis  for  cooperation 

1  between  man  and  machine  (Ref  5:7). 
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The  logical  answer  to  cooperation,  then,  lies  in  utilizing 
both  people  and  computers  in  a  manner  consistent  with  their 
strengths.  It  is  obvious,  therefore,  that  people  should  not  be 
called  upon  to  do  the  kind  of  work  that  a  computer  can  do 
better.  It  should  be  equally  obvious,  as  well,  that  computers 
should  not  be  called  upon  to  be  substitute  people.  The  future 
will  undoubtedly  lead  to  ever  greater  computer  maturity,  to  the 
point  where  some  human  functions  can  be  paralleled  or 
duplicated.  The  present,  however,  would  seemingly  be  better 
served  if  people  and  computers,  each  with  their  relatively 
mutually  exclusive  spheres  of  advantage,  were  deliberately  and 
constructively  meshed  together. 

With  this  view  in  mind,  human  beings  could  more  profitably 
gain  from  computers  if  computers  were  creatively  linked  to 
enhance  their  speed,  throughput,  and  intercommunication.  And, 
such  computer  systems  would  better  profit  people  who  use  them, 
if  their  output  and  input  facilities  were  readily  understood, 
easily  manipulated,  functionally  controlable,  and  consumer 
dependent.  The  point  where  interaction  culminates  in 
identifying  the  most  effective  techniques  for  enabling  a  user  to 
access  needed  data  quickly,  easily,  and  in  a  relatively  natural 
manner,  is  the  user-computer  system  interface,  called  the 
man-machine  interface  (Ref  3:1-1). 
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Computer  to  Computer  Interf ace 

Linking  computers  together  is  an  action  to  improve  upon  the 
individual  computer's  capability  and  to  provide  a  more  powerful 
resource  for  users.  Just  as  input  and  output  data  is  a  dominant 
factor  in  the  application  of  single  computers  (Ref  10:119),  so 
it  is  with  multiple  computer  systems.  It  should  not  be 
surprising,  therefore,  that  intercomputer  or  interprocessor 
communication  is  primarily  at  the  data  level  (Ref  12:67). 

Interfacing,  or  linking  computers  together,  is  widely 
discussed  throughout  the  computer  literature.  Many  types  of 
interfacing  are  possible,  and  many  terms  are  used  to  describe 
differing  methods  and  degrees  of  interface.  An  article  in 
Computing  Surveys  presented  a  naming  scheme  or  taxonomy  for 
identifying  various  systems  of  interconnected  computers  (Ref 
2:197-213).  The  scheme  was  presented  as  a  tree  diagram  of  four 
levels,  wherein  the  two  highest  levels  were  concerned  with 
strategic  (policy)  issues  and  the  two  lower  levels  were 
concerned  with  tactical  (implementation)  issues.  The  authors 
defined  two  terms  of  interest  with  regard  to  communication 
interconnection.  The  first  term,  path,  is  a  medium  by  which  a 
message  is  transferred  between  the  other  system  elements,  such 
as  wires  or  buses.  The  other  term  was  switching  element,  an 
"intervening  intelligence"  between  the  sender  and  receiver  of  a 
message.  The  switching  element  affects  the  destination  of  the 
message  in  some  way. 
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Within  this  scheme,  communication  interconnection  is  either 
direct  or  indirect.  A  transfer  path  can  be  either  dedicated  or 
shared,  and  a  variety  of  system  ar chitechures  may  be  employed  to 
interconnect  computers.  As  an  example,  a  multiprocessor  system 
is  described  as  direct,  having  no  need  for  a  transfer  control 
method,  and  using  a  shared  path  transfer  structure  with  a 
central  memory  system  ar chitechure .  As  another  example,  an 
irregular  network  system  architecture  follows  from  an  indirect 
communication  interconnection,  decentralized  routing,  and  a 
shared  transfer  structure.  In  the  authors'  scheme,  the  variety 
of  interconnections  may  range  from  a  complete,  dedicated 
interconnection  to  an  indirectly,  decentralized,  shared  path 
window.  Nonetheless,  the  common  element  used  to  describe  all  is 
the  data  level  communications  path. 

In  any  interconnected  computer  system,  a  protocol  is 
necessary.  "A  protocol  is  essentially  a  set  of  conventions 
between  communicating  processes  on  the  format  and  content  of 
messages  to  be  exchanged  (Ref  1:4-3)."  The  protocol  can  be 
easily  determined  in  some  computer  links  by  simply  adapting  the 
internal  protocol  of  one  of  the  individual  computers. 

In  all  cases,  computers  are  interconnected  to  benefit  the 
users.  The  better  and  clearer  the  interconnection  of  computers, 
the  less  likely  the  confusion  between  man  and  machine. 
Further,  the  more  likely  will  be  the  usefulness  of  the  system 
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level  and  is  the  starting  point  for  future  interconnection 
efforts . 

Command  Language  Interfacing 

The  problem  of  interfacing  the  NOVA/ECLIPSE  computers  with 
other  computer  systems  is  one  of  command  language  interfacing, 
in  which  the  goal  is  to  construct  a  general  purpose  command 
language  that  provides  the  means  for  computer  to  computer 
dialog.  This  is  another  element  of  computer  to  computer 
interfacing,  in  which  the  connecting  feature  is  a  command 
language  itself.  Command  languages  collectively  form  a  category 
of  intercomputer  connectivity,  in  which  the  type  and  purpose  of 
a  command  language  may  vary  widely  from  use  to  use.  One  of  the 
most  widely  recognized  command  languages  is  that  of  the  UNIX 
(trademark  of  Bell  Laboratories)  Time-Sharing  System  developed 
by  the  Bell  Telephone  Laboratories  (Ref  11:1905),  in  which  the 
most  visible  system  interface  is  the  "shell"  or  command 
language  interpreter,  through  which  other  programs  are  called 
into  execution  singly  or  in  combination  (Ref  6:1900).  The  UNIX 
shell  is  a  high-level  programming  language  that  provides  users 
with  an  interface  into  process  related  facilities  of  the  UNIX 
operating  system.  The  language  is  powerful,  concise,  flexible, 
and,  once  it  becomes  familiar,  easy  to  use.  It  serves  as  a 
useful  basis  of  comparison  for  other  command  languages  and  was  a 
source  of  guidance  for  this  project.  However,  the  degree  of 
difference  between  the  developed  command  language  for  the 
NOVA/ECLIPSE  system  and  the  UNIX  shell  is  singularly 
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significant.  To  meet  the  particular  constraints  of  this 
project,  the  NOVA/ ECLIPSE  command  language  was  developed  as  an 
interpretive  process  that  examines  tailored  files,  called  action 
files,  for  individually  connective  systems.  In  fact,  the 
pattern  of  development  parallels  the  so-called  PROCEDURE  files 
utilized  within  the  CDC  NOS/BE  (Ref  7:5-21  -  5-38). 

The  CDC  PROCEDURE  files  allow  several  CDC  CYBER  commands  to 
be  combined  and  ordered  as  desired  into  a  single  package  for 
execution.  Each  file  has  a  header  and  body,  of  which  the  header 
statement  starts  the  header.  The  header  starts  with  the  keyword 
PROC.,  contains  the  name  of  the  procedure,  and  ends  with  the 
names  of  arguments  to  be  used  within  the  procedure.  The  next 
statements  of  the  file  are  the  body,  and  the  body  is  terminated 
with  an  end-of -record .  The  body  is  made  up  of  control 
statements,  which  are  inserted  into  the  job  control  stream  when 
the  PROCEDURE  file  is  called  into  execution.  The  PROCEDURE  file 
is  called  into  execution  by  a  call-by-name  statement  or  by  a 
call  statement  that  begins  with  BEGIN.  The  operating  system 
makes  the  appropriate  parameter  and  variable  substitutions 
within  the  PROCEDURE  file,  and  then  executes  the  file's  body  of 
statements.  Thus,  via  PROCEDURE  files,  users  of  NOS/BE  may 
combine  a  sequence  of  control  statements  (commands)  into  a 
single  command  with  a  variable  number  of  arguments.  The  entire 
sequence  may  be  executed  by  a  single  reference  to  the  name  of 
the  PROCEDURE  file,  eliminating  the  need  for  a  user  to  repeat 
minor,  often  used  commands,  such  as  REWIND.  It  also  allows  the 
computer  operating  system  to  keep  track  of  the  entire  command 
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sequence  without  user  intervention. 


The  NOVA/ECLIPSE  Computers 

The  DGC  NOVA  and  ECLIPSE  computers  are  both  16  bit  machines 
installed  within  the  digital  signal  processing  facility  of  the 
AFIT  EE  department.  The  NOVA  2/10  and  the  ECLIPSE  S/250  share  a 
ten  megabyte  disk  through  an  Inter-Processor  Buffer,  which 
arbitrates  simultaneous  disk  access.  Each  computer  operates 
under  a  Real-Time  Disk  Opei^ating  System  (RDOS),  which  is 
partially  resident  in  core  memory  as  well  as  on  the  disk  itself. 
Each  operating  system  starts  with  generation  of  SYSGEN,  a 
program  that  permits  the  RDOS  to  be  tailored  to  the  hardware  and 
software  configurations  available  at  a  location.  This  system 
generated  program  includes,  among  other  things,  the  number  of 
printers,  the  number  of  teletypes,  and  the  number  of  other 
devices  to  be  connected  to  and  recognized  by  the  operating 
system.  The  SYSGEN  created  program  for  the  ECLIPSE  is  called 
ESYS;  the  SYSGEN  created  program  for  the  NOVA  is  called  NSYS. 
NSYS,  however,  includes  the  generation  of  a  secondary  teletype 
for  both  input  and  output,  denoted  by  device  codes  $TTI1  and 
$TT01 ,  respectively.  Once  a  device  code  is  system  generated, 
the  operating  system  identifies  the  interrupts  of  the  device  and 
appropriate  handling  procedures.  This  investigation  required 
user  defined  interrupts  and  handlers  for  these  two  particular 
devices.  Hence,  another  program  was  generated,  called  NSYS1,  in 
which  the  operating  system  (RDOS)  did  not  "know"  about  device 
codes  $TTIl  and  $TT01 . 


Though  both  the  NOVA  and  ECLIPSE  may  share  disk  files, 
there  are  differences  in  their  hardware  features  and 
capabilities.  The  AF1T  EE  department  decided  to  use  the  NOVA 
computer  as  the  interface  link  to  any  other  connected  system  and 
most  peripherals,  thereby  freeing  the  larger  and  faster  ECLIPSE 
for  actual  processing  of  data.  In  the  remainder  of  this  thesis, 
therefore,  the  term  NOVA/ ECLIPSE  will  be  used  to  indicate  that 
both  the  NOVA  and  ECLIPSE  computers  are  available,  yet  only  the 
NOVA  is  utilized  in  the  actual  interfacing  to  the  connected 
systems.  Thus,  all  device  codes  and  descriptions  may  be 
thought  of  as  pertaining  only  to  the  NOVA  2/10. 

In  order  to  connect  any  other  computer  system  to  the 
NOVA/ECLIPSE  computers,  access  is  required  to  the  computers 
themselves.  It  was  decided  to  make  use  of  standard  RS-232 
interface  connectors  and  modem  links,  wherein  the  NOVA  device 
codes  of  $TTI1  and  $TT01  would  serve  as  device  ports  for  the 
connected  system.  Information  from  the  NOVA/ECLIPSE  to  the 
connected  computer  system  would  be  transmitted  via  device  code 
$TT01 .  Information  from  the  connected  computer  system  to  the 
NOVA/ECLIPSE  would  be  transmitted  via  device  code  $TTI1. 
Because  of  the  way  RDOS  operates,  each  device  code  used  must  be 
assigned  an  integer  channel  number.  Accordingly,  throughout  the 
software  and  documentation  that  is  developed,  device  codes  and 
channel  numbers  will  refer  to  the  same  entities,  particular 
device  codes  and  individual  channel  numbers  being  equated  at 
various  t ime s . 
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The  basic  method  of  interaction  with  the  RDOS  is  through 
the  Command  Line  Interpreter  (CLI),  a  program  that  accepts 
command  lines  from  the  console  and  translates  them  into  RDOS 
commands.  Through  the  CLI,  high-level  compilers  like  FORTRAN 
may  be  invoked,  as  well  as  the  assembler  and  other  utilities. 
Interface  into  the  RDOS  can  also  be  achieved  via  system  calls 
and  task  calls.  Both  of  these  calls  were  utilized  within  the 
development  of  the  software  for  this  project.  Essentially,  the 
RDOS  can  be  addressed  directly  via  system  calls  in  a  program. 
The  general  form  of  a  system  call  is  (Ref  9:3-1): 

. SYSTM 

command  mnemonic 
error  return 
normal  return 

The  mnemonic  .SYSTM  precedes  each  system  command,  which  passes 
control  through  the  RDOS  task  scheduler  to  the  system  call 
processor,  a  core-resident  portion  of  RDOS.  The  task  monitor 
saves  the  program  (or  task)  environment  in  a  special  block 
called  a  Task  Control  Block  (TCB)  and  saves  the  contents  of 
location  16,  the  User  Stack  Pointer  (USP),  before  passing 
control  to  the  call  processor.  Upon  execution  of  a  system  call, 
the  RDOS  takes  the  error  return  if  it  encounters  some  impediment 
while  executing  the  call.  Accumulator  two  contains  an  error 
code  that  describes  any  error  condition  and  may  be  displayed  by 
the  user.  If  the  call  succeeds,  the  RDOS  takes  the  normal 
return.  System  calls  are  detailed  in  the  RDOS  Reference  Manual, 
Chapter  3  (Ref  9:3-1  -  3-12).  A  task  call  is  similar  to  a 
system  call,  except  for  the  following  points.  Task  calls  have 
no  .SYSTM  mnemonic  before  the  task  command  mnemonic.  The  RDOS 
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executes  task  calls  in  user  address  space,  whereas  system  calls 
are  executed  in  operating  system  space.  And  finally,  many  task 
calls  have  no  error  returns.  The  details  of  task  calls  may  be 
found  in  the  RDOS  Reference  Manual  as  well  (Ref  9:5-1  -  5-8). 
Other  conventions  of  the  RDOS  and  NOVA/ ECLI PSD  computers  will 
be  introduced  and  explained  as  encountered  in  the  discussion  of 
the  project  development. 

Modes  of  Oper a t i on 

The  most  direct  method  of  connecting  the  local  NOVA/ECLIPSE 
computers  to  any  other  computer  system,  particularly  the  locally 
accessible  CDC  CYBER  system,  is  via  a  standard  RS-232  interface 
link  to  one  of  many  available  modems.  The  simplest  method  of 
interconnection  is  to  allow  a  local  NOVA  terminal  to  act  as  a 
transparent  CYBER  terminal,  i.e.,  as  if  the  NOVA  terminal  were 
directly  connected  to  the  CYBER  and  not  the  NOVA.  This  requires 
a  software  interface  that  allows  the  NOVA  computer  to  accept 
data  in  from  the  CYBER,  display  to  the  local  terminal,  and 
vice-versa.  This  at  least  allows  access  via  the  NOVA  computer 
to  the  connected  computer  system,  but  it  does  not  allow  file 
transfers  or  any  other  direct  intercommunication  between 
systems.  Thus,  to  extend  the  concept  further,  additional 
software  is  needed  to  enable  direct  access  from  one  computer  to 
the  other.  One  method  of  doing  this  is  to  create  a  program  to 
mesh  the  NOVA  with  a  particular  system  to  the  degree  that  files 
on  either  system  are  accessed  by  the  user  on  the  NOVA.  It  was 


recognized  early  that  such  software  should  be  designed  to  be 


independent  of  a  particular  system.  Hence,  a  more  general 
software  product  was  desired  that  allows  interaction  between  the 
NOVA/ECLIPSE  and  a  variety  of  other  computer  facilities. 

Since  each  computer  system  is  somewhat  different,  a  method 
was  needed  to  confront  these  differences  in  a  general  fashion  by 
the  local  NOVA/ECLIPSE  system.  If  a  particular  segment  of  the 
software  was  designed  to  be  compatible  with  a  particular 
connected  system,  then  the  NOVA  would  have  to  be  able  to  select 
that  software  and  use  it  on  demand.  Further,  the  act  of 
selection  should  not  tie  the  NOVA  to  the  selected  system,  as  a 
different  system  nay  be  desired  at  a  later  time.  To  meet  these 
constraints,  the  pattern  of  a  so-called  action  file  was 
conceived,  based  upon  the  general  concepts  of  a  PROCEDURE  file 
as  utilized  in  the  CDC  NOS/BE. 

To  extend  this  concept  to  the  local  NOVA/ECLIPSE  system, 
both  the  action  file  (patterned  after  the  PROCEDURE  file)  and  a 
method  of  reading  and  acting  upon  the  action  file  was  required. 
Once  one  or  more  action  files  could  be  constructed  on  the  NOVA 
system,  how  could  they  be  utilized?  In  the  simplest  context, 
the  action  file  may  be  thought  of  as  a  simple  list  of  command 
sequences  to  be  executed  by  the  system.  A  method  was  needed  to 
read  each  sequence  of  instructions  and  send  them  to  the 
connected  system  to  be  executed.  This  presented  additional 
considerations.  First  of  all,  the  action  file  sequences,  if 
more  than  one,  must  be  distinguishable  from  each  other.  When 
and  where  would  one  sequence  start  and  end?  Secondly,  the 
connected  system  may  respond  at  some  time  and  in  some  fashion  to 
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inputs,  perhaps  requiring  that  responses  somehow  be 
acknowledged.  Thus,  what  responses  would  be  expected  and  how 
or  when  should  they  be  acknowledged?  Thirdly,  sending 
instructions  to  the  connected  system  limits  the  local  system  in 
taking  independent  action.  Thus,  there  must  be  some  capability 
of  instructing  the  local  system  in  the  midst  of  action  file 
execution.  Each  of  these  considerations  and  questions  led  to 
the  idea  of  an  action  file  interpreter  —  a  program  that  would 
seek  out  the  desired  action  file,  initiate  and  terminate 
selected  command  sequences,  allow  for  responses  to  the  connected 
system,  and  alert  the  local  NOVA/ECLIPSE  system  to  necessary 
inputs  and  outputs.  Thus,  the  basic  idea  for  computer  to 
computer  dialog  regarding  the  NOVA/ECLIPSE  system  revolved 
around  the  design  and  development  of  action  files  peculiar  to 
possible  connected  systems  and  a  general  interpreter  for  the 
action  files.  The  process  of  designing  these  began  by 
considering  a  specific  system  to  work  with,  and  the  natural 
choice  was  the  CYBER  system. 
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III.  Development  o f  the  Program 

The  development  of  the  software  to  permit  the  NOVA/ECLIPSE 
computers  to  be  interconnected  to  another  computer  system  was 
done  in  a  top-down  manner,  using  successive  refinement.  This 
chapter  describes  the  software  development  of  three  specific 
software  parcels:  (a)  program  TTERMOP,  (b)  program  MONITOR,  and 
(c)  the  action  files.  The  program  TTERMOP  is  a  program  that 
allows  the  user  on  the  NOVA/ECLIPSE  terminal  to  operate  in  the 
transparent  terminal  only  mode.  The  program  MONITOR  is  the 
command  language  interpreter  that  reads  and  acts  upon  selected 
action  files.  The  action  files  are  created  in  a  prescribed 
manner  that  meets  the  expectations  of  the  interpreter.  The 
action  file  referenced  within  this  text  is  that  created  and 
implemented  to  intercommunicate  with  the  CDC  CYBER  computer 
system.  The  development  of  MONITOR  and  the  action  files  was 
interdependent  and  cannot  be  artificially  separated. 
Nonetheless,  the  following  text  does  treat  the  development  of 
each  somewhat  separately,  first  describing  the  generation  of  the 
action  files  and  then  the  program  MONITOR.  Before  these 
discussions  are  presented,  some  theory  and  background  concerning 
the  development  are  presented,  in  order  to  acquaint  the  reader 
with  the  overall  concepts  and  implementation  conventions. 
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Development  Theory  and  Background 


After  analyzing  the  problem  and  deciding  that  three 
partitionable  software  products  were  to  be  developed  —  program 
TTERMOP,  program  MONITOR,  and  the  action  files  —  the 
alternative  methods  of  accomplishment  and  the  tools  to  be  used 
in  the  development  were  considered.  Some  factors  bearing  upon 
the  considerations  were  the  stated  objectives  of  the  solution  to 
the  problem  itself.  The  program  MONITOR  should  be  as  flexible 
as  possible,  so  as  to  be  utilized  with  as  many  connected 
systems  as  possible.  Also,  program  MONITOR  should  be  as 
general  as  possible,  so  as  to  be  a  completely  portable  (to  the 
degree  possible)  program  that  could  be  hosted  on  other  systems, 
in  addition  to  the  NOVA/ ECLIPSE .  This  dictated  that  the  action 
files  be  dependent  upon  the  connected  system  for  content,  but 
independent  of  the  connected  system  as  far  as  structure.  One 
final  factor  was  to  develop  a  system  that  enabled  the 
NOVA/ECLIPSE  computers  to  interact  with  the  CDC  CYBER  computer 
system . 

In  consideration  of  these  factors,  the  software  needed  to 
be  developed  in  as  high-level  a  language  as  permissible,  thereby 
supporting  its  generality.  PASCAL  was  a  logical  choice.  A 
structured  language,  such  as  PASCAL,  leads  to  simplified  data 
structures  and  more  straightforward  file  structure 
manipulations.  In  addition,  PASCAL  has  powerful  features,  such 
as  recursion,  that  enable  complex  algorithms  to  be  more  readily 
designed  and  developed.  Nonetheless,  PASCAL  was  not  available 
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on  the  NOVA/FXLIPSE  computers  at  the  time  of  development. 
Other  structured  languages  that  seemed  to  lend  themselves  to 
this  type  of  undertaking  were  not  available  either.  FORTRAN  IV 
and  FORTRAN  V  were  available.  FORTRAN  IV  was  selected  because 
it  was  available,  is  a  high-order  language,  and  is,  perhaps,  as 
universal  a  language  as  exists.  FORTRAN  V  was  not  selected 
because  of  the  case  for  FORTRAN  IV  and  the  fact  that  FORTRAN  V 
is  essentially  a  superset  of  FORTRAN  IV.  Thus,  if  a  user 
chooses,  FORTRAN  IV  may  be  extended  to  FORTRAN  V.  It  also 
seemed  reasonable  at  the  outset  to  expect  to  use  some  assembly 
language  programs  to  implement  device  handlers  and  routines  that 
depended  heavily  upon  the  operating  system  characteristics. 
Thus,  both  the  DGC  FORTRAN  IV  and  assembly  languages  are  used  to 
develop  the  software  parcels.  Some  variations  from  the 
American  National  Standards  Institute  (ANSI)  standard  FORTRAN 
were  utilized,  but  only  to  enhance  readability  and 
understanding.  None  of  the  uses  would  preclude  adaptation  to 
other  system  FORTRAN  versions,  depending  upon  the  assembly 
language  that  may  be  required  for  another  system. 

Transparent  Terminal  Mode .  The  idea  to  create  a 
transparent  terminal  mode  of  operation  was  two-fold.  First, 
the  terminal  mode  would  at  least  allow  access  to  another  system. 
Depending  upon  the  ultimate  limitations  of  a  command  language, 
such  a  mode  would  be  desirable  to  permit  detailed  interaction 
with  a  connected  system  not  possible  at  the  higher  level  of  the 
command  language.  Further,  such  a  mode  would  serve  as  a  handy 
option  for  transitioning  in  the  middle  of  any  command  langauge 
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execution.  Secondly,  the  development  of  a  terminal  mode  would 
be  a  prelude  to  other  developments.  Such  a  prelude  would 
provide  system  familiarization  and  understanding  in  a  less 
complex  environment. 

The  first  and  major  obstacle  in  developing  the  program 
TTERMOP  was  the  method  of  interaction  to  be  implemented  between 
connected  systems.  The  transparent  terminal  mode  needs  to  be 
controlled  by  the  user  at  the  local  NOVA  terminal.  Outputs  to 
the  connected  computer  system  are  generated  by  entries  made  by 
the  terminal  user.  However,  responses  from  the  connected  system 
are  less  controlled,  and,  more  generally,  may  vary  from  one 
system  to  another.  There  may  be  responses  during  the  access 
initiation  process,  after  individual  instructions  are  received, 
or  upon  other  occasions  unexpected  by  the  user.  Implementat i on 
of  interrupt  servicing  seemed  the  logical  alternative  to 
overcome  this  control  problem  in  the  most  general  case.  This, 
in  turn,  also  lead  to  a  problem  in  implementation,  for 
interrupts  are  usually  serviced  by  the  operating  system  for 
devices  known  by  the  system,  i.e.,  generated  when  the  system  is 
initially  brought  up  to  operation.  In  order  to  usp  interrupts, 
then,  either  the  system  generated  interrupt  service  routines  had 
to  be  changed  to  allow  different  interrupt  handling,  or  the 
interrupts  had  to  be  removed  from  the  purview  of  the  operating 
system  and  be  generated  by  the  developed  software.  The  latter 
alternative  was  chosen,  since  changing  the  operating  system 
handlers  was  more  complex  and  would  still  leave  the  handlers  in 
the  system.  Other  users  with  other  programs  would  not 
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necessarily  find  changed  operating  system  handlers  useful  or 
expected.  As  mentioned  in  Chapter  II,  the  device  codes  to  be 
used  for  purposes  of  intercommunication  are  $TT0l  and  $TTU. 
Both  these  devices  and  their  codes  are  removed  in  the  system 
generated  program  NSYS1.  Thus,  development  of  TTERMOP  was  now 
possible  using  defined  interrupts  and  handlers  within  the 
software  itself. 

A  second  obstacle  existed  that  hindered  TTERMOP 
development.  Even  though  interrupts  were  available  to  permit 
servicing  for  the  two  NOVA/ECLIPSE  port  devices  ( $TT01  and 
$TTI1),  the  program  software  needed  to  respond  to  both  the  local 
terminal  inputs  and  outputs  —  interrupts  that  remained  defined 
by  the  operating  system  —  and  the  connected  system  inputs  and 
outputs  —  interrupts  that  were  program  defined.  The 
possibility  existed  that  the  program  might  be  servicing  one  of 
these  sets  of  inputs/outputs,  and  lose  input  s/output s  from  the 
other  set.  Some  method  of  asynchronous  interaction  was  needed 
to  insure  both  sets  of  input s / out  put s  were  equally  and  promptly 
handled.  The  NOVA/ ECLIPSE  system  has  such  a  capability,  called 
multitasking  (Ref  7:5-1+).  Multitasking  permits  a  single 
program  to  contain  multiple,  competitive  tasks.  A  task  is  a 
complete,  self-contained  execution  path  through  a  program,  which 
demands  system  resources.  In  a  single  task  environment,  a 
program  has  a  single  unified  path  connecting  all  its  program 
logic,  no  matter  how  complex  the  logic  branches.  In  a 
multitask  environment,  a  program  may  have  two  or  more  logically 
distinct  tasks,  each  with  its  own  priority.  Each  of  these 
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distinct  tasks  performs  a  specified  function  asynchronously  and 
in  real-time.  In  the  RDOS,  the  Task  Scheduler  allocates 
central  processor  control  to  the  highest  priority  task  that  is 
ready  to  perform  its  function.  The  multitasking  feature  of  the 
RDOS  is  used,  then,  to  put  the  interrupts  for  the  connected 
system  into  one  task  for  processing,  while  the  interrrupts  for 
the  NOVA  terminal  are  put  into  a  logically  distinct  task.  To 
insure  the  user  maintains  control,  the  task  that  controls  the 
NOVA  terminal  is  given  the  higher  priority. 

The  Action  Files.  The  concept  for  the  action  file  came 
directly  from  the  CDC  NOS/EE  PROCEDURE  files  (Ref  7:5-21  - 
5-38),  A  separate  action  file  was  conceived  for  particular 
computer  systems  to  be  interfaced  with  the  NOVA/ECLIPSE 
computers.  Each  action  file  contains  a  sequence  of  commands,  of 
which  each  command  in  the  sequence  instructs  either  the 
NOVA/ECLIPSE  or  the  connected  system.  These  instructions  serve 
the  same  purpose  as  the  body  of  the  PROCEDURE  file,  i.e.,  they 
provide  the  control  statements  necessary  for  execution  of  a 
command.  The  header  statement  of  the  action  file  was  conceived 
to  be  essentially  the  same  as  that  for  the  PROCEDURE  file.  It 
contains  a  keyword  that  identifies  the  action  file,  such  as 
.CACT  for  the  CYBER  action  file.  The  keyword  is  followed  by  a 
command  name  and  argument  parameters.  To  facilitate 
segregation  of  each  sequence  from  the  next,  another  keyword  is 
inserted  into  the  file  between  sequences.  This  keyword  is  END.. 
Similarly,  to  denote  the  end  of  the  action  file,  the  keyword 
FINISH,  is  used.  To  allow  the  action  file  to  be  as  powerful  as 
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possible,  and  .hence,  the  interpreter  as  general  as  possible,  a 
method  to  incorporate  expected  system  responses  is  developed. 
At  the  beginning  of  each  action  file,  the  control  character  "1" 
must  be  included  .  It  is  followed  by  up  to  two  separate 
responses  that  may  be  expected  of  the  system.  (These  responses 
are  used  in  the  interpreter  to  detect  the  occurrence  of  system 
responses  and  to  detect  the  end  of  such  responses.)  Other 
features  of  the  action  files  follow  logically  from  the 
requirements  of  the  program  MONITOR. 
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MONITOR  is  the  fundamental  part  of  the  software  package. 
Program  MONITOR  is  developed  to  instruct  the  interactive  user 
step  by  step  in  the  execution  of  the  software  that  forms  the 
command  language.  Thus,  the  program  first  identifies  itself  via 
a  display  on  the  user's  terminal  (NOVA/ECLIPSE)  and  identifies 
the  action  files  that  are  available  for  selection.  (Four  action 
files  are  available  to  the  user,  of  which  only  one  is  totally 
implemented.  The  others  are  shells  that  await  future 
completion.  The  complete  action  file  is  for  the  CDC  CYBER 
computer  system,  called  .CACT  .  Two  action  files  are  for 
computers  that  are  accessible  locally,  even  though  connections 
have  not  been  attempted.  They  are  called  . DACT  and  .VACT  .  The 
last  action  file  is  completely  arbitrary,  and  is  available  for 
any  user  to  generate  as  desired.  This  file,  called  .MACT, 
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presents  the  ultimate  in  flexibility  —  the  creation  of  a 
totally  user-defined  and  user-modif  iable  action  file  for  any 
system.)  Program  MONITOR  requests  the  user  to  select  an  action 
file  and  then  requests  the  user  to  LOGON.  (Procedures  for  LOGON 
and  the  other  commands  are  contained  in  the  MONITOR  User 
Manual,  Appendix  A.)  To  notify  the  user  that  a  response  is 
required,  program  MONITOR  provides  a  prompt.  Program  MONITOR 
also  screens  input  commands  to  determine  if  they  are  valid;  for 
example,  rejecting  commands  not  within  the  action  file,  commands 
that  are  too  long,  commands  that  are  without  the  necessary 
arguments,  and  commands  that  contain  syntax  errors. 

Program  MONITOR  was  developed  in  a  simple  configuration  to 
expedite  its  implementation.  In  this  configuration,  commands 
arc  required  to  be  entered  and  followed  by  exactly  the  number  of 
arguments  expected,  that  is,  the  number  of  arguments  indicated 
after  the  command  name  in  the  action  file.  Furthermore, 
commands  must  be  in  the  same  order.  There  are  no  optional 
arguments  nor  default  arguments.  This  configuration  simplifies 
the  decision-making  of  the  interpreter  with  regard  to  parameter 
substitution.  Also,  there  are  two  control  options  that  the  user 
may  exercise  at  any  time  in  lieu  of  command  strings.  One  of 
these  is  the  entry  "~T" ,  (an  up-arrow  and  T)  which  causes  the 
program  MONITOR  to  relinquish  control  to  the  terminal  operation 
only  mode.  The  other  option  is  the  entry  "“L" ,  (an  up-arrow 
and  L)  which  causes  a  return  to  the  RDOS  CLI. 

A  similar  obstacle  to  that  of  TTERMOP  hindered  development 
of  MONITOR.  This  was  the  control  of  inputs  and  outputs  of  the 


connected  system  and  inputs  and  outputs  of  the  NOVA/ ECLIPSE . 
The  solution  was  again  multitasking,  with  one  task  monitoring 
NOVA/ECLIPSE  input/output  and  the  other  task  monitoring  the 
connected  system's  input/output.  An  additional  obstacle  not 
encountered  before  concerned  instructing  the  NOVA/ECLIPSE  RDOS 
from  within  the  program  MONITOR.  As  the  program  MONITOR 
executes  in  RDOS  already,  some  method  to  exit  the  program 
MONITOR  is  needed  in  order  to  instruct  RDOS  via  its  own  command 
language,  the  CLI.  It  is  equally  necessary,  however,  to  be  able 
to  reenter  MONITOR  immediately  after  any  instruction  is  passed 
to  RDOS,  and  to  enter  at  the  location  from  which  the  exit 
occurred.  One  feasible  means  of  doing  this  is  to  swop  out  the 
program  MONITOR,  swap  in  the  RDOS  CLI,  and  then  swap  righl  bach 
to  the  program  MONITOR.  The  process  of  swapping  is  available  on 
the  NOVA/ECLIPSE  system  via  system  and/or  task  calls  to  the 
operating  system. 

Swapping  as  implemented  on  the  DGC  system  is  a  process 
whereby  a  program  is  called  by  name  into  execution.  The  calling 
program  is  swapped  out  of  memory  and  the  called  program  is 
swapped  into  memory.  Within  the  RDOS,  the  CLI  normally  operates 
on  what  is  called  level  zero.  This  is  the  highest  of  five 
possible  levels  of  program  execution.  When  a  typical  program  is 
called  into  execution  by  the  CLI,  the  program  is  executed  on 
level  one.  In  effect,  the  CLI  is  swapped  out  of  memory  and  the 
executing  program  is  swapped  into  memory.  Going  from  one  level 
to  another  is  essentially  a  stack  operation.  If  the  CLI  is 
executing  on  level  zero  and  a  program  is  called  into  execution, 
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tlie  executing  program  is  pushed  onto  the  stack.  Returning  to 
the  CLI  at  the  program's  conclusion  is  essentially  a  pop  of  the 
stack.  The  latest  program  on  the  stack  is  the  level  being 
executed.  If  the  CLI  is  executing  on  level  zero,  it  is  not 
possible  to  execute  another  program  from  the  CLI  without  that 
program  starting,  execution  at  its  beginning.  The  ability  to 
communicate  with  RDOS,  however,  can  be  accomplished  as  desired 
by  calling  the  CLI  into  operation  on  level  two.  Then,  when  the 
CLI  execution  is  complete,  an  appropriate  pop  of  the  stack  will 
return  to  the  level  one  program.  Furthermore,  the  return  will 
be  to  the  location  from  which  the  program  called  the  CLI  into 
execution  on  level  two.  Executing  the  CLI  on  level  two  can  be 
limited  to  a  single  instruction  or  a  group  of  instructions  that 
are  passed  at  the  time  of  the  call  to  swap  to  the  CLI.  The 
process  is  described  more  completely  in  the  RDOS  Reference 
Manual,  Chapter  4  (Ref  7:4-2). 

Dev e 1 p pment  o f  TTERMOP 

As  mentioned  earlier,  the  port  device  codes  $TTI1  and  $TT01 
were  incorporated  into  the  software  of  TTERMOP  and  MONITOR, 
rather  than  leaving  the  operating  system  to  define  them  in  its 
SYSGEN  program.  The  advantage  of  identifying  the  device  codes 
at  run  time  is  that  new  interrupt  handlers  can  be  designed  to 
handle  interrupts  as  desired.  By  doing  this,  any  input  to  the 
NOVA/ECLIPSE  computers  from  the  connected  computer  system 
generates  an  interrupt  via  device  code  $TT11.  The  interrupt 
service  routine  essentially  accepts  the  input  and  stores  it  in  a 
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buffer  for  later  disposition.  Similarly,  any  output  from  the 
NOVA/KCLIPSE  computers  to  the  connected  compuLer  system 
generates  pn  interrupt  via  device  code  $TT01  .  This  interrupt 
service  routine  simply  clears  the  particular  interrupt,  allowing 
the  connected  computer  to  handle  the  NOVA/ECLTPSE  output  in  its 
own  fashion.  (It  should  be  noted  that  all  input  and  output  is 
1 -.Eli  ted  to  ASCII  characters  in  all  the  software  developed.) 

Once  the  input  from  the  connected  computer  system  is 
received  by  the  NOVA  (where  in  fact  the  device  ports  exist)  and 
is  stored  in  a  buffer,  a  separate  section  of  code  disposes  of 
the  buffer  itself.  Two  oointers  are  established.  One  pointer, 
called  INPTR ,  points  to  the  next  empty  location  in  the  buffer. 
The  other  pointer,  called  OUTPTP.,  points  to  the  last  buffer 
location  actually  disposed  of  by  program  TTERMOP.  If  the  buffer 
has  not  been  accessed  by  the  program,  OUTl’TR  started  and  remains 
at  the  buffer's  beginning.  If  the  INPTR  and  OUTPTR  point  to  the 
same  location,  the  program  knows  that  the  buffer  is  "empty." 
Conversely,  whenever  the  pointers  are  not  the  same,  input  has 
been  received  and  stored  in  the  buffet.  The  buffer  itself  is 
designed  to  be  132  characters  long.  This  arbitrary  length  was 
selected  with  the  reasonable  expectation  that  the  buffer  would 
never  overflow,  i.e.,  that  the  INPTR  would  not  be  132  characters 
ahead  of  the  OUTPTR  at  any  time.  The  expectation  seemed 
particularly  reasonable  when  considering  the  300  baud  rate  of 
the  CDC  CYBER,  used  as  the  implementing  connected  system.  This 
should  be  the  case  for  higher  baud  rates  as  well,  particularly 
1200  baud.  Even  at  rates  up  to  4800  baud,  the  buffer  should  be 
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adequate. 

The  section  of  code  in  program  TTERMOP  that  looks  at  the 
buffer  continually  is  named  LINERD ,  and  is  called  as  a  separate 
task  within  the  multitasking  framework  of  the  program  TTERMOP. 
LINERD  has  a  priority  of  ten,  whereas  the  main  task  of  TTERMOP, 
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terminal  and  transmits  it  directly  to  the  connected  system  via 
device  code  $TT01 .  The  task  LINERD  simply  takes  input  from  the 
input  buffer,  and  displays  it  to  the  NOVA  terminal.  In 
operation,  then,  the  user  generates  output  and  usually  awaits 
input.  Since  the  output  program  has  higher  priority,  the  user 
controls  the  program.  While  the  user  awaits  input,  the  lower 
priority  task  LINERD  seizes  control  of  the  processor  to  look  for 
that  input.  At  rates  up  to  at  least  1200  baud,  both  tasks 
appear  to  operate  simultaneously  and  are  in  fact  seizing  control 
on  a  character  by  character  basis. 

Program  TTERMOP  has  several  parts  to  it.  The  program 
contains  the  separate,  logical  tasks  LINERD  and  TERMED.  The 
program  also  has  the  system  calls  to  identify  and  generate 
device  codes  $TT01  and  $TTI1.  Finally,  TTERMOP  has  the 
interrupt  handlers  defined  within  its  source  code  also. 
Altogether,  the  program  provides  the  necessary  software  to  make 
the  NOVA/ECLIPSE  user  operate  off  of  the  connected  system,  in 
particular  the  CYBER  system,  transparently.  Since  the  majority 
of  the  functions  dealt  with  in  this  program  are  at  the  device 
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driver  level,  the  entire  source  code  is  assembly  language.  A 
higher-level  flowchart  of  the  program  TTERMOP  is  not  explicitly 
provided.  However,  a  flowchart  for  program  TERMOP  contained  in 
Appendix  B  is  exactly  the  same  for  TTERMOP,  and  may  be  referred 
to  for  information  concerning  TTERMOP. 

Program  TTERMOP  is  executed  by  entering  the  directory 
DIALOG  and  typing  on  the  NOVA  terminal  TTERMOP.  Once  a 
telephone  connection  via  a  modem  is  established  between  the 
CYBER  and  the  NOVA/ ECLIFSE ,  all  subsequent  terminal  action  is  as 
if  the  NOVA  terminal  were  directly  connected  to  the  CYBER.  All 
NOVA/ECLIPSE  operations  are  transparent  to  the  user  during  the 
execution  of  the  program  TTERMOP.  Exit  from  TTERMOP  may  be 
accomplished  by  typing  in  an  up-arrow  at  any  time,  thus 
reverting  the  user  to  the  RDOS  CLI. 

Development  of  the  Action  Files 

One  of  the  very  first  things  considered  when  starting  the 
construction  of  the  general  purpose  interface  for  the 
NOVA/ECLIPSE  computers  was  the  minimum  number  of  instructions 
required  as  input  by  a  connected  computer  system,  in  order  for 
that  system  to  execute  functions  on  its  own  file  structure. 
This  minimal  set  of  instructions  formed  the  initial  action  file 
and  served  as  a  forerunner  of  the  final  product.  As  stated  in 
Chapter  II,  the  CDC  CYBER  PROCEDURE  files  were  the  pattern 
behind  the  design  of  the  action  files.  Thus,  the  initial  action 
file  was  closely  structured  after  the  PROCEDURE  file.  Both 
files  have  header  statements  that  declare  the  name  and  arguments 
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0f  a  particular  command  sequence.  Both  files  have  a  body  of 
statements  that  consist  of  the  control  command  sequences,  and 
both  files  have  all  entries  arranged  sequentially.  This 
sequential  arrangement  is,  in  turn,  the  logical  and  convenient 
means  by  which  to  examine  the  action  files.  Once  the 
interpreter  selects  an  appropriate  action  file  and  receives  a 
command  input,  the  file  is  sequentially  examined  from  the 
beginning  until  a  command  name  matches  the  input  command.  Once 
the  match  is  made,  each  instruction  within  the  sequence  is  acted 
upon  and  executed  sequentially  as  well.  Keywords  are  inserted 
within  the  action  file  to  isolate  instruction  sequences  and 
indicate  file  beginning  and  end.  Again  borrowing  heavily  from 
the  PROCEDURE  file,  the  start  of  each  action  file  is  simply  the 
file  itself.  The  start  of  a  particular  command  sequence  in  the 
file  is  denoted  by  a  single  period  appearing  as  the  first 
character  in  the  line  of  the  sequence,  followed  by  a  descriptor. 
The  descriptor  for  the  CDC  CYBER  action  file  is  the  word  ".CACT" 
.  This  descriptor  is  followed  by  the  name  of  the  command 
sequence  and  any  arguments  as  required.  The  arguments  are 
simply  a  series  of  sharpsigns  (#)  and  integers,  which  denote 
the  order  and  position  of  the  arguments  in  the  header 
statement.  (As  noted  earlier,  position  is  fixed.)  Each  entry  is 
arbitrarily  separated  by  commas.  After  this  first  line, 
referred  to  as  the  action  file  header,  is  a  list  of  command 
instructions  that  comprise  a  command  sequence.  To  delimit 
individual  command  instruction  sequences,  the  keyword  "END."  is 
used.  Finally,  to  indicate  the  last  line  in  the  action  file, 
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the  keyword  "FINISH."  is  inserted.  Figure  1  shows  a  skeletal 
outline  of  an  action  file  for  the  CDC  CYBER  as  presented  thus 
f  ar . 


. CACT , COMMANDNAMEl , #1 ,# 2 

YYYYY  dummy  instructions  that 

ZZZZZ  form  a  command  sequence 

END. 

. CACT , COMMANDNAME  no  arguments 

YYYYY 

ZZZZZ 

END. 

. CACT , COMMANDNAMEN , #1 , #2, . . . ,  #N 
YYYYY 

ZZZZZ 

END. 

FINISH. 


Fig  1.  Skeletal  Command  Action  File 


With  respect  to  the  action  file,  the  command  language 
interpreter  reads  the  action  file,  matches  the  desired  command 
name,  and  then  sends  the  instructions  within  the  matched 
command  sequence  to  the  connected  system  or  to  the  local 
NOVA/ECLIPSE  system  for  execution.  To  simplify  the  decision 
process  of  the  interpreter,  the  action  file  includes  control 
characters  within  each  command  sequence  to  direct  interpreter 
handling.  Each  of  these  control  character  sets  has  two  control 
characters.  For  example,  an  instruction  within  the  sequence 
that  calls  for  writing  to  the  local  NOVA  terminal  is  preceded  by 
the  control  character  set  WL.  Other  examples  of  control 
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character  sets  are  WS,  write  to  the  connected  system;  RS,  read 
from  the  connected  system;  and  RW ,  read  from  the  local  system 
terminal  and  then  write  a  single  carriage  return  to  the 
connected  system.  Two  particular  control  character  sets  are  RC 
and  WC.  These  character  sets  precede  an  instruction  that  is 
directed  to  the  NOVA/ ECLIPSE  RDOS .  The  first  set  results  in  a 
disk  file  on  the  NOVA/ECLIPSE  being  read  and  copied  to  the 
connected  system.  The  second  set  results  in  a  file  being 
written  to  the  NOVA/ECLIPSE  disk  from  information  copied  from 
the  connected  system.  These  character  sets  put  into  motion  a 
swap  to  the  RDOS  CLI,  as  explained  briefly  in  Chapter  II  and 
more  fully  described  in  the  next  section. 


C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  SENT 

C  CORRECT  INPUT  IS:  PUT , LFN , SFN , ID , SFPASSWRD 

. CACT , PUT , #1 , #2 , #3 , #4 

WS  COPYBF, INPUT, ZQY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, ZQY 

WS  REQUEST , ZQZ , *PF 

WS  COPYBF, ZQY, ZQZ 

WS  CATALOG , ZQZ , #2 , ID=#3 , RP=999 , PW=#4 

WS  RETURN, ZQZ, ZQY 

END. 

C  THIS  COMMAND  RECEIVES  SYSTEM  FILES 
C  CORRECT  INPUT  IS:  GET , SFN , ID , SFPASSWRD , LFN 

. CACT, GET, #1, #2, #3, #4 
WS  ATTACH , QZQ, #1 , ID=#2 , PW=#3 

RR 

WS  COPYSBF.QZQ, OUTPUT 

RC  XFER/A  VVQQ  # 4/R 

WS  RETURN, QZQ 

END. 


Fig  2.  Sample  from  CYBER  Action  File 
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An  exapple  portion  of  the-  final  CYBER  action  file  is 
illustrated  in  Figure  2.  The  first  command  name  shewn  is  PUT. 
This  command  takes  a  disk  file  resident  on  the  NOVA/ECLIPSE 
system  and  transfers  the  file  to  permanent  storage  on  the  CDC 
CYBER  system.  The  command  name  PUT  is  preceded  by  the  keyword 
.CACT  and  followed  by  the  place  holders  for  four  arguments. 
Therefore,  the  PUT  command  requires  four  arguments.  In  order, 
these  arguments  must  be  the  local  file  name  (including  any 
directory  specifiers)  of  the  NOVA/ECEIPSF.  disk  file,  the  system 
file  name  to  be  used  on  the  CYBER,  the  user  identification 
number  or  problem  number  the  file  is  to  be  stored  under,  and  the 
CYBER  syst  m  passwords.  (Since  each  argument  parameter  is 
required,  a  parameter  must  be  used  for  the  password.  In  this 
case,  and  only  in  this  case,  a  zero  entry  may  be  used  to 
indicate  no  password.)  The  first  instruction  in  the  PUT  command 
sequence  is  preceded  by  WS,  and,  as  with  all  instructions, 
arbitrarily  starts  in  column  nine.  Thus,  the  instruction 
consisting  of  the  string  —  COPYBF, INPUT, ZQY  —  is  to  be  sent  to 
the  CYBER.  The  next  command  in  the  sequence  is  preceded  by  WC. 
This  means  that  the  file  with  the  name  entered  in  the  position 
of  argument  one  is  to  be  copied  from  the  NOVA/ECLIPSE  disk  to 
the  CYBER  system.  All  the  rest  of  the  commands  in  the  sequence 
are  preceded  by  WS,  and  explicitly  instruct  the  CYBER  to  store 
the  transferred  file  into  permanent  file  storage,  the  user  input 
arguments  having  been  substituted  for  the  argument  parameters 
within  the  action  file  by  manipulation  of  the  interpreter.  The 
command  sequence  terminates  with  END. 
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The  second  command  name  shown  is  GET.  This  command  takes  a 


file  in  permanent  storage  on  the  CYBER  and  transfers  the  file 
to  the  NOVA/ECLIPSE  disk.  The  command  GET  is  also  preceded  by 
the  keyword  .CACT  and  followed  by  the  placeholders  for  four 
arguments.  The  treatment  of  these  four  arguments  is  exactly  the 
same  as  that  for  PUT,  with  the  order  and  position  strictly 
observed.  Hence,  the  arguments  in  order  must  be  the  system  file 
name,  the  user  identification  number,  the  system  file  password, 
and  the  local  file  name.  The  commands  in  the  sequence  preceded 
by  WS  are  handled  exactly  as  described  for  PUT  above.  A  blank 
command  line  is  preceded  by  the  control  character  set  RR,  which 
is  sufficient  to  tell  the  interpreter  that  the  local 
NOVA/ECLIPSE  needs  to  ready  itself  for  a  read  from  the  CYBER. 
Essentially,  the  character  set  RR  activates  a  subroutine  to 
create  a  temporary  file  that  will  subsequently  be  written  into, 
when  the  next  instruction  in  the  action  file  preceded  by  RC  is 
executed.  The  command  line  preceded  by  RC  is  just  the  converse 
of  the  command  line  preceded  by  V/ C .  In  this  case,  file  transfer 
takes  place  from  the  CYBER  to  the  NOVA/ ECLIPSE .  Again,  the 
command  sequence  is  terminated  by  the  keyword  END. 

Finally,  single  control  characters  are  used  outside  of  the 
command  sequence.  The  control  character  C,  for  example, 
indicates  that  the  remainder  of  the  line  is  a  comment  that  the 
interpreter  may  ignore.  (There  is  one  other  single  control 
character  --  I  --  used  elsewhere  in  the  action  file.  It 
indicates  that  up  to  two  responses  of  the  connected  system  may 
follow.  Even  if  no  responses  are  expected  nor  entered,  the 
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control  character  I  must  be  in  the  action  file  as  the 
interpreter  always  looks  for  it.) 

Development  of  MONITOR 

Program  MONITOR  is  the  largest  software  partition  utilized 
in  interfacing  the  NOVA/KCLIPSE  computers  to  other  connected 
computer  systems.  MONITOR  serves  as  the  basic  command  string 
interpreter  of  the  action  files  discussed  previously,  and  acts 
as  the  executive  to  control  functional  interactions  of  all 


subroutines  and  any  tasks.  There  are 

two 

tasks 

that 

execute 

asynchronously  within  MONITOR. 

The 

main 

task 

is  the 

interpreter/ execut ive  program  MONITOR, 

and 

the 

other 

task  is 

called  SYS1N,  for  system  input.  This  latter  task  continually 
monitors  and  seeks  any  input  from  the  connected  system.  In 
fact,  SYSIN  is  an  extension  to  TTERMOP,  doing  all  the  same 
functions  of  TTERMOP,  plus  others  to  be  developed  below. 

The  MONITOR  Task.  In  the  narrowest  focus,  the  program 
MONITOR  reads  the  action  file  selected  by  a  user,  and,  upon 
matching  the  desired  command  name  and  related  command  sequence, 
sends  the  command  sequence  lines  to  the  connected  computer 
system  or  to  the  NOVA/ECLIPSE  RDOS.  In  order  to  interpret  the 
action  file,  the  file  itself  has  to  be  read  into  storage.  The 
simplest  method  to  accomplish  this  is  to  use  FORTRAN  read 
statements  that  store  the  file  in  a  one-dimensional  array,  one 
line  at  a  time.  As  the  action  files  are  exclusively  ASCII,  the 
A  format  specification  is  used  in  the  READ  statements.  As  each 
line  is  read  into  the  array,  the  keywords  or  control  characters 
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arc  examined  to  determine  further  actions.  Prior  to  taking  any 
of  these  further  actions,  the  arguments  must  be  resolved. 

A  typical  command  instruction  within  the  command  language- 
may  include  no  arguments  or  up  to  four  arguments.  Argument 
substitution  then  allows  the  user  flexibility  in  selecting 
arguments  to  be  used  with  any  particular  action  file.  The 
method  of  argument  substitution  developed  is  simple  and  proceeds 
as  follows.  A  command  string  consists  of  a  command  name 
optionally  followed  by  arguments.  Each  argument  of  a  command 
string  is  entered  sequentially  after  the  command  instruction 
name.  The  command  and  arguments  are  separated  either  by  commas 
or  blanks,  where  two  blanks  or  two  commas  together  indicate  a 
null  argument.  Order  must  be  fixed,  and  is  determined  by  the 
action  file.  An  easy  way  to  identify  the  arguments  in  the 
action  file  is  to  number  them  sequentially,  using  the?  sharpsign 
as  an  indicator.  For  example,  argument  two  is  denoted  i?  2  and 
argument  x  is  denoted  #x.  Not  all  command  sequence  instructions 
within  the  action  file  contain  argument  parameters.  In  fact, 
there  are  certain  sequences  that  may  be  checked,  while  the 
others  may  be  ignored  for  this  purpose.  The  interpreter, 
therefore,  checks  all  command  sequence  instructions  that  are 
preceded  by  the  control  character  set  in  which  the  second 
character  is  either  an  "S"  or  a  "C"  .  In  these  instances,  the 
process  of  argument  substitution  is  four-fold.  First  of  all, 
the  array  containing  the  command  sequence  line  is  checked  to 
determine  if  any  sharpsigns  exist.  If  not,  the  argument 
substitution  process  ceases.  If  a  sharpsign  exists,  the  array 
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the  sharpsign  and  its 


is  collapsed  about  the  sharpsign,  i.c., 
corresponding  number  are  removed  from  the  array.  Next,  in  the 
same  location  where  the  sharpsign  and  number  were,  the  array  is 
expanded  to  the  size  of  the  argument  entered  by  the  user.  Once 

this  step  is  complete,  spaces  exist  where  the  sharpsign  and 

number  used  to  be.  Ir.  the  last  step  of  the  substitution 

procedure,  these  spaces  are  replaced  by  the  argument.  This 

four-fold  process  is  then  repeated  until  all  argument 
placeholders  in  any  particular  command  sequence  line  have  been 
substituted  wiLh  actual  arguments.  Several  error  checking 
procedures  are  in  effect  prior  to  and  throughout  this  process. 
If  an  argument  is  too  long  (maximum  length  40  characters)  or  if 
arguments  supplied  by  the  user  do  not  match  exactly  the 
arguments  expected  by  the  action  file,  error  messages  are- 
provided  to  the  user. 

Once  arguments  are  resolved  in  any  command  sequence- 
instruction,  the  control  characters  dictate  what  action  the 
interpreter  is  to  Lake  next.  Each  action  is  supported  by  one  or 
more  subroutines  that  program  MONITOR  calls  into  execution.  For 
example,  in  the  command  PUT,  one  of  the  command  sequence 

instructions  is  preceded  by  the  control  character  set  WS.  Upon 
resolving  the  arguments  in  this  instruction,  the  program  MONITOR 
calls  FORTRAN  subroutine  WRITSYSTM  to  implement  the  action  of 
writing  the  instruction  to  the  connected  system.  WRITSYSTM  is 
really  just  a  transition  subroutine  that  smooths  the  transfer 
from  the  FORTRAN  program  MONITOR  to  the  assembly  language 
program  WRSYS,  a  subroutine  called  by  WRITSYSTM.  WRSYS  actually 
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dm  s  the  voi  k  oi  t  t  a  [■  r.n  i  1 1 1  n;;  t  lu  command  instruction  to  the 
cornu  fled  systcn. .  The  transfer  is  Linde  character  by  character. 
Several  other  subroutines  parallel  these  two.  For  a  control 
character  ret  of  RK  ( read  f ron  the  local  system  and  write  a 
carriage  return  to  the  connected  system),  the  interpreter  calls 
FOkTRAh  subroutine  RFALLVK1TS,  which  transitions  to  the  assembly 
language  routine  RDAWR .  For  a  control  character  set  of  WL 
(vrile  to  the  local  terminal),  program  MONITOR  calls  FORTRAN 
6  ub  routine  WK1TL0CAI. ,  wliich  does  not  call  any  other  routines. 
The  contiol  character  set  RR  (ready  the  NOVA/ECLIPSE  for  a 
subsequent  read  that  will  take  place),  causes  the  interpreter  to 
call  FORTRAN  subroutine  READYRF.AD.  READYREAD  simply  creates  a 
file  to  be  used  as  temporary  storage  for  the  information  that 
will  subsequently  be  copied  from  the  connected  system.  Two 
other  control  character  sets  are  similar,  though  converses  of 
each  other.  The  set  WC  (write  a  copy  of  a  NOVA/ECLIPSE  disk 
file  to  the  connected  system)  prompts  program  MONITOR  to  call 
FORTRAN  subroutine  SENDFILE.  SENDFILE  serves  primarily  as  a 
transition  routine  and,  secondarily,  as  a  mini-executive  of  the 
actions  necessary  for  such  a  transfer.  SENDFILE  calls  assembly 
language  subroutines  EXCLI  and  GETF1LE.  Program  EXCLI  is  called 
to  execute  the  RDOS  CLI  on  level  tv/o  by  swapping  the  CLI  in  and 
the  program  EXCLI  (or  effectively  MONITOR)  out  of  memory. 
During  the  swap,  the  instruction  contained  in  the 
one-dimensional  action  file  array  (called  IACTFILE)  is  sent  to 
the  RDOS.  Upon  return  from  the  swap,  program  GETFILE  is  called. 
This  program  actually  gets  the  disk  file  that  is  to  be 
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transmitted  and  outputs  the  entire  contents  of  the  file 
character  by  character  to  the  connected  system.  The  converse 
of  the  character  set  WC  is  RC  (read  a  copy  of  a  connected  system 
file  and  store  on  the  NOVA/ECLIPSE) .  The  interpreter  responds 
to  the  control  character  set  RC  oy  calling  FORTRAN  subroutine 
RECKVF1LL.  Like  SE11DF1LE,  RECF.VF1LE  also  calls  assembly 
language  routine  EXCLI  in  order  to  send  instructions  to  the 
RDOS  .  Because  of  the  structure  of  SYSIN,  described  below,  the 
information  from  the  connected  system  has  already  been  received 
and  stored  in  a  temporary  file.  Thus,  execution  of  EXCLI  at 
this  time  simply  transfers  the  input  file  from  this  temporary 
disk  storage  to  the  file  location  input  by  the  user  as  an 
argument . 

The  remaining  programs  called  by  MONITOR  are  mere  a  part  of 
its  executive  functions,  rather  than  interpretive  functions. 
Two  programs  that  blur  this  distinction  somewhat  are  GETRSPS 
and  CNVBT.  FORTRAN  program  GETRSPS  is  called  by  MONITOR  shortly 
after  initiation,  yet  subsequent  to  user  selection  of  the 
desired  action  file.  This  program  reads  the  action  file 
selected,  looking  for  control  character  I  (mentioned  earlier). 
Entries  in  the  action  file  after  this  character  are  initial 
responses  (up  to  two)  that  may  be  expected  from  the  connected 
system  during  interconnection.  For  example,  in  the  CYBER  action 
file  the  entry  in  the  line  after  control  character  I  is 
"COMMAND-,.."  ,  The  comma  serves  as  a  separator,  indicating  two 
possible  responses  that  may  be  expected  from  the  CYBER  during 
interconnection  with  the  NOVA/ ECL IPSE .  The  first  response  is 
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"COMMAND-"  and  the  second  response  is  .  GETRSPS  simply 
gets  these  responses,  if  any,  from  the  selected  action  file  and 
stores  them  in  arrays.  Upon  return  from  GETRSPS,  MONITOR 
immediately  calls  assembly  language  routine  CNVRT.  The  sole 
function  of  CNVRT  is  to  convert  the  FORTRAN  array  storage  of 
GETRSPS  into  assembly  language  storage.  For  example,  the  ASCII 
character  "A"  is  stored  in  the  FORTRAN  array  as  Lv;o  bytes  in  one 
16  bit  word,  of  which  the  octal  representation  is  <101><40>. 
The  same  character  is  stored  in  assembly  language  as  <0><101>. 
The  difference  between  these  two  stems  from  the  difference 
between  the  FORTRAN  A  format  specification  used  in  reading  in 
the  array  and  the  assembly  language  construction  that  docs  not 
use  special  formating.  In  essence,  the  FORTRAN  read  statement 
puts  a  single  character  into  one  word,  the  left  byte  the  actual 
ASCII  character  code  and  the  right  byte  a  space.  Assembly 
language  looks  at  bytes  only.  Thus,  a  16  bit  word  will  have  a 
null  in  the  left  byte-  and  the  actual  ASCII  representation  in  the 
right  byte.  CNVRT  then  stores  the  needed  character 
representation  of  the  responses  and  their  size  in  buffers  that 
are  used  by  subsequent  programs  to  assist  the  interpreter  in 
detecting  responses  from  the  connected  system  and  determining 
whether  or  not  they're  expected. 

Those  programs  that  arc  purely  executive  are  the  programs 
BCIN,  PROMPT,  REVERT,  and  TOTERM.  Each  of  these  carries  out  a 
specific  function  that  needs  to  be  accomplished  to  help 
integrate  the  various  modules  of  MONITOR  into  a  working  whole. 
BCIN  simply  opens  channels  to  the  local  NOVA/ECLIPSE  terminal 
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input 


and  output  device  codes  --  $TT1  and  $TTO  --  respectively. 
PROMPT  provides  prompt  character  ll>"  to  the  user's  terminal 
whenever  called.  Tnc  program  REVERT  is  selected  by  the  user  as 
an  option  in  lieu  of  a  command  string.  By  entering  the  string 
"~L"  ,  the  user  instructs  the  interpreter  to  return  to  the  RDOS 
CLI.  REVERT  simply  executes  the  return  to  the  CLI.  The  user 
also  lias  the  option  of  entering  the  string  "'T"  .  This  string 
instructs  the  interpreter  to  go  to  the  terminal  operation  only 
mode.  In  essence,  the  program  TTt'KMOP  is  called,  although  as  a 
subroutine  it  is  slightly  modified  and  renamed  TERMOP.  MONITOR 
actually  calls  TOTERM,  which  first  removes  the  previously 
defined  device  codes  $TT01  and  $TT11,  and  then  calls  TERMOP. 
Appendix  R  contains  a  flowchart  description  of  program  MONITOR 
and  its  v a r  i o us  modules. 

Th  e  SX?J_N  T  a  si; .  As  each  of  the  interpretive  and  executive 
functions  of  MONITOR  are  being  executed,  a  separate  task  is  also 
called  into  execution  by  MONITOR.  Using  a  PGC  FORTRAN  version 
task  call,  program  SYS1N  is  activated  at  the  beginning  of 
program  MONITOR.  SYSIN  is  given  a  priority  of  one,  while 
MONITOR  is  automatically  assigned  a  priority  of  zero.  In 
keeping  with  the  RDOS  conventions,  MONITOR  has  the  higher 
priority. 

SYS1N  has  four  basic  actions  to  accomplish.  First,  when 
SYSIN  is  initially  called,  it  identifies  and  defines  the  needed 
device  codes  $TT01  and  $TTI1.  The  remaining  three  actions  occur 
as  the  processor  schedules  the1  task  itself.  The  first  action 
taken  by  SYSIN  is  to  continually  check  the  input  buffer  that  may 
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have  been  receiving  data  from  the  connected  system.  Any  data 
received  is  put  into  another  buffer,  called  MATBUFR,  for 
matching  purposes.  Next,  the;  program  SYSIN  compares  the  data 
put  into  the  match  buffer  with  the  expected  responses  from  the 
connected  system.  (These  responses  were  stored  in  retrievable 
locations  by  program  CN'VRT.)  If  the  responses  are  as  expected, 
the  match  buffer  is  cleared  and  new  information  is  entered  into 
it.  If  the  responses  are  not  expected,  SYSIN  displays  them  on 
the  NOVA  terminal  for  the  user  to  see.  Finally,  SYSIN  always 
checks  to  see  if  a  temporary  disk  storage  file  has  been  created 
by  the  program  READYREAD.  If  no  such  file  is  created,  then 
SYSIN  does  nothing  extra  and  returns  to  repeat  the  other 
actions.  If  the  file  has  been  created,  however,  then  SYSIN 
writes  the  information  in  the  match  buffer  into  the  temporary 
disk  file  as  well.  Thus,  SYSIN  creates  the  device  interrupt 
routines  for  device  codes/ports  $TT0l  and  $TTI1,  monitors  the 
input  buffer,  detects  and  appropriately  displays  responses  from 
the  connected  system,  and  writes  to  a  temporary  disk  file  when 
such  a  file  exists.  Flowcharts  that  describe  SYSIN  are  also 
contained  in  Appendix  B. 

Handshaking  Convent  ions .  Because  of  peculiarities  in  the 
RDOS  with  regard  to  its  scheduling  of  user  created  tasks  and 
because  of  the  relatively  slow  response  from  the  connected 
computer  system  (currently  operating  at  300  baud),  several 
handshaking  conventions  available  via  task  calls  have  been 
utilized  throughout  the  program  MONITOR.  Basically,  whenever  an 
instruction  has  been  sent  to  the  connected  computer  system  by 
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any  routine  or  subroutine  of  the  command  language,  the  main  task 
MONITOR  is  suspended.  The  main  task  remains  suspended  until  the 
secondary  task  SYS1N  readies  the  MONITOR.  SYSIN  readies  MONITOR 
after  any  response  from  the  connected  system  or  after  a  built-in 
time  delay  has  been  exceeded.  The  asynchronous  nature  of  the 
two  tasks  is  affected  by  this  implementation,  but  only  after  a 
suspension  of  the  main  task.  Both  tasks  remain  independent  and 
asynchronous  when  both  are  active.  The  handshaking  permits  the 
user  to  control  events  through  the  interpreter,  as  MONITOR  is 
the  task  that  the  user  communicates  with.  This  handshaking  and 
the  rel at ionship  of  all  programs  that  constitute  the  command 
language  are  presented  graphically  in  Figure  3.  Each  assembly 
language  program  depicted  is  given  the  file  name  extension  .SR, 
while  each  FORTRAN  program  is  given  the  file  name  extension  .FR. 
All  the  programs  shown  in  the  figure  are  loaded  together  and 
executed  under  the  file  name  MONITOR. SV.  The  mechanics  of  the 
loading  and  execution  are  briefly  discussed  in  Appendix  C. 
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REVERT. SR 
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PROMPT. SR 


BGIN.SR 


GETRSPS.FR 
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-  indicates  task  interaction 

-  indicates  subroutine  call  and  return 

-  indicates  subroutine  call  and  no  return 

Fig  3.  Program  MONITOR  Structure  Chart 
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IV.  V  a  1 1 d  a  t ion 


The  general  purpose  command  language  was  constructed  in  a 
modular  manner  from  the  top  down.  The  initial  program  devloped 
and  tested  was  the  main  task  MONITOR.  Until  other  needed 
modules  were  completely  developed,  stubs  were  created  and  used 
to  interact  with  the  main  task.  Tasking  itself  was  not  needed 
and  vms  not  introduced  until  the  software  effort  was  fifty 
percent  complete.  The  remainder  of  this  chapter  discuss  the 
testing  and  validation  efforts  with  respect  to  the  c.  .and 
language  development  and  construction.  The  fiist  section 
discusses  efforts  during  the  development,  while  the  second 
section  discusses  efforts  once  a  workable  product  was  p-  ■'duced  . 

Puri  UK  Development 

Every  effort  was  made  during  development  to  completely  test 
and  debug  modules  as  they  were  created  and  modified.  Most  of 
the  modules  were  short  and  uncomplicated,  enabling  repeated 
assembling  and  loading  without  extensive  time  delays.  Those 
modules  that  were  more  unwieldly,  such  as  SYSIN  and  MONITOR, 
were  developed  and  tested  in  stages.  A  tool  frequently  used  to 
great  advantage  was  the  DGC  RDOR  Symbolic  Debugger.  The 
debugger  saved  many  manhours  in  tracking  down  sporadically 
appearing  errors.  Perhaps  the  main  feature  of  the  debugger  that 
permitted  this  savings  was  the  ability  to  set  breakpoints  and 
execute  up  to  these  breakpoints. 
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Many  trial  modules  were  created  in  the  project's  beginning 
to  test  system  calls,  FORTRAN  calls,  and  subroutine 
interactions.  A  significant  amount  of  time  was  spent  trying  to 
integrate  FORTRAN  programs  with  assembly  language  programs.  In 
this  regard,  several  small  scale  FORTRAN  programs  and  their 
called  FORTRAN  subroutines  were  created  and  compiled.  The 
NOVA/ ECLIPSE  RDOS  requires  each  distinct  routine  or  subroutine 
to  be  separately  compiled  or  assembled.  Because  of  this, 
compiled  FORTRAN  programs  produce  an  optional  assembly  language 
file.  These  files  were  examined  repeatedly  to  determine  the 
exact  relationship  between  FORTRAN  and  assembly  language 
programs.  Essentially,  the  assembly  language  routines  require 
calls  to  specific  FORTRAN  runtime  library  routines  at  the 
program  beginning  and  end.  These  library  routines  initialize 
variables  and  organize  stacks  automatically,  thereby  enabling 
communication  and  interaction  from  a  FORTRAN  module  to  an 
assembly  language  module.  Another  complication  was  establishing 
the  FORTRAN  address  locations  for  compiler  generated  and 
temporary  variables  within  the  assembly  language  routines. 
This  is  always  accomplished  at  the  end  of  an  assembly  language 
subroutine  by  setting  the  variables  used  in  the  assembly 
language  program  to  FORTRAN  address  locations  expected  by  the 
FORTRAN  main  module.  FORTRAN  calls  to  RDOS  routines  and  system 
calls  within  assembly  language  routines  also  required  repeated 
examination  and  trials  to  determine  their  effects.  Once 
familiar,  these  types  of  calls  proved  quite  powerful  and 
convenient.  It  should  be  noted,  however,  that  complications  can 
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and  did  arise  when  mixing  user  defined  operations  that  executed 
in  user  space  with  systen  calls  that  executed  in  system  space. 
In  fact,  system  calls  cannot  be  used  at  all  in  user  defined 
interrupt  service  routines.  Finally,  extra  code  was  used 
regularly  to  provide  messages  to  the  user  terminal  regarding 
decision  points  encountered  and  overcome.  For  example,  the 
one-diment  ion;  1  array  IACTFILE  that  contai  ned  the  command 
sequence  instruction  from  Lhe  action  file  was  repeatedly 
displayed  on  the  terminal  screen  throughout  the  argument 
substitution  piocess.  This  provided  clear  and  immediate 
feedback  as  to  the  program's  progress  and  correctness  during 
execution. 

No  computer  link  was  available  for  testing  the  interfacing 
programs  until  late  in  the  development,  nor  was  it  needed  until 
late  in  the  development.  Initially,  therefore,  a  simple  line 
printer  was  connected  to  the  input  and  output  ports  of  the 
KOVA/F.CLI  PSE .  Early  programs  were  tested  by  writing  to  this 
printer  and  ignoring  inputs  (since  there  were  none).  About 
halfway  through  the  development,  the  printer  was  replaced  by  a 
separate  terminal.  Later  versions  of  the  interfacing  programs 
provided  for  writing  to  this  terminal  and  reading  from  this 
terminal.  Thus,  two-way  communication  was  established.  The 
program  TTERMOP  was  essentially  proofed  in  this  testing 
configuration,  since  computer  to  computer  dialog  for  this 
program  was  easily  simulated.  Interrupts  were  generated  and 
serviced,  and  responses  were  user-simulated  as  if  the  terminal 
that  was  connected  to  the  access  ports  of  the  NOVA/ ECLIPSE  was 
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indeed  the  CYBER  computer.  During  this  entire  period  of  time, 
no  major  attempt  was  made  to  streamline  or  enhance  coded 
procedures.  The  first  goal  was  to  make  the  program  execute 
successfully. 

After  Development 

Once  the  programs  were  complete  and  individually  tested  in 
the  terminal  to  terminal  environment,  the  emphasis  shifted  to 
integrated  program  validation.  All  independent  aspects  of  the 
individual  modules  were  correctly  compiled,  assembled,  and 
loaded  together  without  any  explicit  errors  discerned  by  the 
RDOS .  By  this  same  time,  all  stubs  had  been  replaced  by  working 
routines  and  the  intial  refinements  had  been  made.  At  this  same 
time,  the  telephone  link  to  the  local  CDC  CYBER  computer  system 
was  installed.  Initial  attempts  to  interconnect  the 
NOVA/ECLIPSE  computers  to  the  CYBER  system  failed  due  to  pin 
mismatches  in  the  RS-232  connectors.  Once  these  pin  connections 
were  changed,  computer  interconnection  was  achieved.  Program 
TTERMOP  worked  well  almost  immediately,  only  requiring 
modifications  that  eliminated  sections  of  code  that  simulated 
modem  functions  for  operation  in  the  terminal  to  terminal  mode . 
Program  MONITOR  had  more  severe  problems,  revolving  around 
handshaking  considerations  for  the  multiple  tasks  in  the  command 
language  interpreter.  These  problems  were  most  difficult  to 
isolate  for  two  reasons.  First,  the  debugger  was  limited  to 
setting  breakpoints  only  within  a  single  task.  That  is,  if 
breakpoints  were  set  in  each  task,  the  debugger  would  halt  at 
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the  first  breakpoint  encountered  in  either  task  and  would 
remain  in  that  task.  The  other  task  was  not  visible  through 
the  debugger  in  this  instance.  The  second  reason  quickly 
overshadowed  the  first  reason.  The  debugger,  and  in  fact  the 
entire  MONITOR  program  would  not  execute  at  all  once  the  entire 
program  was  loaded  together.  The  debugger  and  all  other 
programs  loaded  without  error,  but  a  FORTRAN  runtime  error 
indicating  a  stack  overflow  resulted  whenever  an  attempt  was 
made  to  execute  the  complete  program.  It  appears  that  resident 
memory  is  too  small  to  handle  the  execution  of  the  integrated 
program  with  the  debugger.  Nonetheless,  the  handshaking 
problems  were  corrected  by  using  task  calls  to  appropriately 
suspend  and  ready  the  main  task,  which  allowed  the  secondary 
task  to  seize  control  of  the  processor  as  desired. 

Repeated  failure  of  the  program  SYSIN  to  suppress  displays 
of  expected  responses  from  the  CYBER  computer  system  lead  to  the 
discovery  of  another  problem.  The  CYBER  terminal  sends  out 
sequences  of  null  characters  at  various  times.  These  nulls  are 
accepted  in  the  input  buffer,  but  are  not  visible  to  the 
terminal  user.  Even  so,  they  cause  the  matching  routine  of 
SYSIN  to  give  erroneous  results.  The  solution  is  simply  to 
discard  all  nulls  received  by  the  NOVA/ ECLIPSE .  This  corrected 
the  problem  of  detecting  and  suppressing  expected  responses  from 
the  connected  CYBER  system. 

Early  attempts  to  execute  commands  of  the  developed  command 
language  were  intermittently  successful.  Numerous  minor  changes 
were  made  to  the  action  files  to  correct  command  sequences, 
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syntax,  and  spacing.  To  save  some  time  and  preclude  potential 
problems,  the  interpreter  was  modified  so  as  to  send  only  the 
exact  number  of  characters  comprising  a  command  instruction. 
Prior  to  this  modification,  an  entire  record  line  of  80 
characters  was  sent,  even  if  the  command  string  was  less  than  80 
characters.  As  these  changes  were  made,  the  program  became 
progressively  more  reliable. 

File  transfers  have  been  accomplished  and  the  files  have 
been  checked  for  completeness  and  uniformity.  Files  are 
transferred  as  expected  with  one  exception.  Files  received 
from  the  CI)C  CYBER  system  have  an  extra  carriage  return  attached 
at  the  file  beginning  and  end.  These  can  easily  be  removed 
using  the  text  editor.  Also,  there  were  occassions  when  a  file 
would  be  transmitted  to  the  CYBER  system  from  the  NOVA/ECLIPSE, 
but  upon  completion  of  the  transmission,  the  NOVA  computer  would 
hang  up  about  location  12  (octal).  The  problem  was 
intermittent,  and  could  not  always  be  duplicated.  Nevertheless, 
files  with  less  than  20  bytes  of  information  and  files  with 
upwards  of  35,000  bytes  of  information  have  been  successfully 
and  repeatedly  transferred  both  ways  without  program  failure. 
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V. 


CpncJjasj  on_P  and.  ]’.r  cp.r.n.i  n  d  a  t  i  on  s 

A  general  purpose  cunniaml  1  anguagt1  for  compute-r  to  computer 
dialog  has  been  designed,  developed,  and  implemented.  The 
coiv.ci.ind  language,  called  MONITOR,  met;;  the  basic  constraints 
that  were  established  when  the  problem  was  defined.  The 
program  is  flexible,  which  allows  the  same  software  to  be  used 
for  more  than  one  connected  computer  system  to  the  NOVA/ 1ICLI PSF. 
computers.  However,  until  another  system  other  than  the  CDC 
CYBER  is  actually  interconnected  and  used,  the  degree  of 
flexibility  is  speculative  and  subjective.  The  command 
language  is  general,  to  the  degree  that  it  seems  reasonable  to 
be  able  to  implement  MONITOR  on  another  system  other  than  the 
NOVA/ECLIPSE ,  with  some  modifications.  The  assembly  language- 
routines  must  be  fitted  to  the  assembler  to  be  used,  and  the 
interaction  between  the  TORTkAN  and  the  assembly  language 
routines  may  require  changes.  Only  a  test  will  demonstrate  the 
real  generality  of  this  programming.  The  concept  and  overall 
structure  ,  however,  se-e.-m  most  feasible.  The  interpreter  is  the 
basic  entity  and  should  remain  static  in  most  cares.  The  action 
files  are  system  dependent,  and  they  are  dynamic  by  design. 
Thus,  thee  remainder  of  this  chapter  will  cover  the  conclusions 
and  recommendations  regarding  this  project. 
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rone lus ions 


The  general  purpose  command  language  works  well  overall. 
There  are  a  variety  of  available  commands  and  all  have  been 
successfully  implemented.  ASCII  files  have  been  transferred  to 
and  from  the  NOVA/ECLIPSE  repeatedly,  files  have  been  printed 
on  the  CYBER  printer,  and  files  have  been  punched  on  the  CYBER 
punch . 

The  command  language  is  easy  to  use,  simply  defined,  and 
brief.  There  are  just  a  few  commands,  although  more  can  be 
added  or  deleted.  With  these  limited  commands,  much  work  can  be 
accomplished.  The  user  need  enter  a  limited  number  of  words 
only,  and  is  relieved  of  the  tedium  of  repeated  entries.  Fewer 
commands  encourage  use;  simple  commands  encourage  use. 


The 

command 

langua 

ge  is 

not 

as  universal 

as  conceivable. 

Commands 

are  str 

uctured 

to  fit 

the 

environment 

in  which  they 

are  to  be 

used , 

1 imit ing 

their 

universality  somewhat.  Commands 

are  restricted  to  size,  the  number  of  arguments  possible,  and 
the  order  and  position  of  arguments  are  fixed. 

The  program  is  relatively  slow  executing.  Much  of  this  is 
due  to  the  handshaking  that  has  been  used. 

The  program  is  not  as  efficient  as  it  could  be  with  some 
design  changes.  The  handshaking  has  circumvented  the 
independence  and  asynchronization  of  some  of  the  multitasking 
features  of  the  operating  system.  Swapping  takes  place  although 
some  other  means  to  avoid  swapping  may  exist. 
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Finally,  tin-  programs  arc  structured  inodularly,  lending  to 


ease  of  modification,  readability,  and  understanding. 


K  e  c  orm  o  n  d  a  t  i  o n ; 

The  following  recommendations  are  presented  to  indicat 
areas  in  which  the  general  pupose  command  language  cjjji'5'tr  u  c  t  e  d 
may  be  improved  and  enhanced.  Some  of  the^fc  cowmen  dal  ions 
follow  logically  from  the  conclusions^rcscntf'd  above.  Other 
recommendations  are  just  o  b  s  c  r  v  a J*i«<5n  s  and  suggestions  that  have 
accumulated  over  the  tiiry^of  the  project.  Each  recommendation 
is  presented  in^th^^ffope  that  it  will  either  lead  to  follow-on 
project  opportunities  or  a  better  understanding  of  the  project 
a  s  a^sflTo  1  e  . 

The  current  structure  and  content  of  the  general  purpose 
language  is  not  necessarily  the  most  efficient  nor  the  most 
effective.  There  are  several  assembly  language  routines  that 
might  readily  be  convertible  to  FORTRAN,  and  several  features 
that  have  been  implemented  might  be  simplified.  Logical 
candidates  for  simplification  are  the  routines  EXCLI  and  SYS1N. 
There  may  be  a  more  straightforward  way  to  interact  with  the 
RDOS  from  the  command  language  itself,  for  example. 

Much  more  flexibility  could  be  built  into  the  command 
language  with  respect  to  the  functioning  of  commands.  For 
example,  the  commands  need  not  be  limited  to  simple  command 
strings.  Perhaps  global  and  local  switches  could  be  introduced 
to  increase  the  power  of  the  command  instructions  themselves. 
Further,  argument  defaults  and  optional  arguments  would 
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^cr^ta^rffTy  improve  the  povor  of  the  language. 

The  current  software  has  no  convenient  means  to  internally 
adapt  to  connected  systems  that  arc  full-duplex.  All  the  source 
code  has  been  written  with  a  half -duplex  link  in  mind.  An 
internal  flag  or  switch  to  appropriately  select  code  for  either 
half-duplex  or  full-duplex  operation  would  certainly  increase 
the  universality  of  the  software. 

Current  implementation  of  the  MONITOR  command  language  is 
limited  to  ASCII  file  transfers  only.  Expanding  the  capability 
to  handle  binary  files  would  be  most  useful,  especially  in 
support  of  the  digital  signal  processing  demands. 

With  the  language  implemented  as  it  is,  access  is  now 
available  to  another  computer  system  for  dialog  from  the 
NOVA/ ECLIPSE .  Deviling  a  method  of  access  to  the  NOVA /ECLIPSE 
from  the  other  computer  system  would  open  new  avenues  of  dialog 
between  computers. 

More  sophisticated  command  languages  often  implement 
pipelining,  i.e.,  stringing  command  instructions  sequentially 
for  sequential  execution.  Implementing  pipelining  within 
MONITOR  would  provide  a  terse  language  of  greater  power  and 
convenience  . 

MONITOR  lends  itself  to  coding  in  a  high-level  structured 
language.  Several  advantages  may  be  gained  by  redesigning 
MONITOR  in  PASCAL,  for  example.  Data  structure  and  file 
structure  manipulations  might  be  greatly  simplified  and 
facilitate  greater  creativity  in  developing  command  sequences. 
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1  .  Introduction 

Program  MONITOR  is  a  general  purpose  command  language  that 
may  be  used  for  computer  to  computer  dialog.  The  MONITOR 
software  resides  within  the  Data  General  Corporation  (DGC) 
NOVA/ ECLIPSE  computer  system.  By  calling  upon  particularly 
designed  action  files,  MONITOR  enables  a  user  to 
intercommunicate  with  various  computer  systems  that  are  linked 
to  the  NOVA/ ECLIPSE  via  a  standard  RS-232  modem  connection.  The 
input/output  ports  for  the  NOVA/ECLIPSE  are  called  device  codes 
$TTT1  and  $TT01 ,  respectively.  These  ports  are  on  the  NOVA  2/10 
computer  only.  However,  since  the  NOVA  2/10  and  ECL1TSE  S/250 
share  a  ten  megabyte  disk  via  the  DGC  Real-Time  Disk  Operating 
System  (RDOS),  access  to  the  ECLIPSE  may  also  be  gained  through 
the  NOVA  by  appropriate  operating  system  instructions. 

The  user  desiring  to  utilize  MONITOR  may  use  a  NOVA  video 
display  terminal  within  the  Air  Force  Institute  of  Technology 
( AFIT)  Electrical  Engineering  department's  Digital  Signal 
Processing  Laboratory.  This  user  manual  will  describe  the 
access  procedures,  the  commands  available  for  use,  the  errors 
that  may  be  encountered,  and  the  particular  design  of  an  accion 
file. 

Though  the  command  language  MONITOR  was  designed  to  be  used 
with  different  connected  computer  systems,  only  the  locally 
accessible  Control  Data  Corporation  (CDC)  CYBER  computer  system 
has  actually  been  interconnected.  Thus,  all  examples  and 
specifics  will  refer  to  this  interconnection  throughout  the 
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manual.  A  general  extension  to  other  computer  systems  is 
relatively  straightforward. 
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2  .  How  to  Arcoss/Urc  MON'  IT  OR 

The  executable  software  package  that  enables  computer  to 
computer  dialog  via  the  NOVA/FCLIPSE  computers  is  the  binary 
save  file  MONITOR. SV.  This  file  is  composed  of  several  FORTRAN 
language  and  assembly  language  source  routines  that  are  loaded 
together  to  form  MONITOR. SV.  The  main  partition  of  the  entire 
software  package  is  the  FORTRAN  source  program  MONITOR. FR,  which 
forms  the  basic  command  language  interpreter  and  executive  for 
the  command  language.  (Unless  otherwise  stated  hereafter,  the 
term  MONITOR  will  refer  to  the  binary  save  file  MONITOR. SV.) 

The  software  for  MONITOR  resides  upon  the  NOVA/ECLIPSF 
disk,  specifically  the  NOVA  disk  platter.  The  directory  under 
which  MONITOR  is  stored  is  named  DIALOG.  Therefore,  to  access 
MONITOR,  the  user  must  enter  the  directory  DIALOG.  The 
appropriate  command  by  which  to  enter  the  directory  from  any 
other  directory  is: 

DIR  DPOF: DIALOG 

Once  the  user  has  entered  the  directory  DIALOG,  the  user  is 
ready  to  execute  the  command  language.  The  simple  entry 

MONITOR 

will  call  the  binary  save  file  MONITOR. SV  into  execution.  The 
user  will  next  see  the  following  display  upon  the  terminal 
screen : 
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The  MONITOR  program  you  have  entered  provides 
intercommunication  between  tlie  NOVA/ ECE I  PS E  computer 
system  and  your  choice  of  another  system. 


Please  enter  the  dip, it  opposite  the  action  file 
you  desire  to  use: 

1  —  CDC  CYBER 

2  --  DEC  10 

3  —  VAX  11/780 

4  --  Your  own 


The  character  ">"  is  a  prompt  that  signals  the  user  to  make  an 
entry.  In  the  above  instance,  an  entry  of  1  would  select  the 
CDC  CYDER  action  file,  a  2  the  DEC  10  action  file,  a  3  the  VAX 
11/780  action  file,  and  a  4  an  action  file  developed  and  coded 
by  the  user.  (Originally,  only  the  CDC  CYBER  action  file  was 
developed.  Thus,  the  other  action  files  existed,  but  had  no 
useful  entries.  Effectively,  these  other  files  contained  no 
commands  and  always  returned  an  error  condition  if  commands  were 
attempted  from  them.)  Entry  of  a  number  other  than  those 
indicated  causes  an  error  message  as  follows: 


You  have  entered  an  illegal  number.  Try  again! 

> 

The  user  is  again  at  the  initial  starting  point. 

Once  the  user  has  entered  a  selected  integer,  such  as  1, 
the  following  type  of  message  is  displayed: 
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You  have  selected  the  CYli  HR . 

Thank  you.  Please  enter  a  command. 

> 

At  this  point,  all  preliminary  initializations  of  the  program 
have  taken  place.  The  user  is  nov  ready  to  enter  a  specific 
command  from  the  available  commands  contained  within  the 
selected  action  file,  or  two  additional  commands  not  contained 
within  the  action  file. 

The  two  commands  not  contained  within  any  action  file  are  a 
command  that  reverts  the  user  back  to  the  P.DOS  Command  Language 
Interpreter  (C.LT)  and  a  command  that  calls  the  terminal  only 
mode  of  operation  —  program  TER1I0P  --  into  execution.  The  two 
commands  are: 

'L  -  revert  to  local  CLI 

~T  -  change  to  terminal  only  mode 

The  next  display  a  user  sees  upon  entry  of  ~L  is: 

You  have  returned  to  the  local  CLI  mode. 

R 

The  "R"  is  the  RDOS  CLI  prompt.  The  next  display  a  user  sees 
upon  entry  of  ~T  is: 

You  have  entered  into  the  terminal  only  mode.  Proceed! 

The  user's  terminal  is  now  connected  as  a  transparent  terminal 
to  the  computer  system  selected,  such  as  the  CYBER.  To  exit 
this  mode  and  return  to  the  MONITOR  mode  requires  the  user  to 
enter  an  up-arrow  which  returns  the  user  to  the  RDOS  CLI, 

and  then  to  enter  MONITOR  and  repeat  the  sequences  described 
above . 
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All  other  permissible  entries  are  contained  in  the  action 
file.  To  see  a  complete  list  of  these  commands,  see  the  action 
file  itself.  The  next  chapter  describes  the  original  commands 
developed  and  implemented  within  the  CDC  CYBER  action  file.  As 
action  files  are  designed  to  change,  however,  the  user  must  look 
at  the  current  action  file  to  find  the  current  status  of 
c  ommand  s . 
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3  •  Grip. Inal  ('oc.nnn ds  Av a i  1  abl  c 

The  original  commands  developed  specifically  for  the  CDC 
CYBER  action  file  are  listed  and  briefly  described  below.  These 
commands  (names)  may  be  used  in  other  action  files,  provided 
command  sequences  contained  in  the  action  files  are 
appropriately  designed  and  controlled.  See  Chapter  5  for  a 
discussion  of  the  design  and  structure  of  a  particular  action 
file. 


PUT , LFN , SFN , ID, SFPASSWRD 

This  command  selects  a  local  file  name  (LFN)  from  the 
NOVA/ECM PSE  disk  and  transfers  the  file  to  the  connected 
computer  system.  The  transferred  file  is  stored 
permanently  under  a  system  file  name  (SFN)  with  an 
identification  (ID)  mid  system  file  password  (SFPASSWRD) 
supplied  by  the  user. 


C-ET  ,  SFN  ,  ID,  SI’PA S S W Rb ,  1,  FN 

This  command  selects  a  SFN  stored  on  the  connected  computer 
system  and  transfers  the  file  to  the  NOVA/ECLIPSE  disk  with 
the  LFN  input.  The  user  supplies  the  ID  and  SFPASSWRD  for 
the  SFN. 


SPRINT, SFN, SFPASSWRD 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  on 
the  connected  computer  system  and  prints  the  file  out  on 
the  connected  system  printer. 

S PUNCH , SFN, SFPASSWRD 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  on 
the  connected  computer  system  and  punches  the  file  out  in 
Hollerith  code  on  the  system  card  punch. 
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DELETE  ,  SEN  ,  SFPASS W K D 


This  command  deletes/purges  the  permanent  file  on  the 
connected  computer  system  with  the  SEN  and  SEPASSWRD  input. 


FILES 


This  command  causes  the  connected  system  to  display  local 
files  in  use. 


PFILES 

This  command  causes  the  connected  system  to  display  the 
permanent  files  in  use  for  the  ID  supplied. 

LOGON , USER  ID .USER  PASSWRD 

This  command  initiates  access  to  the  connected  system.  The 
user  must  supply  the  specific  ID  and  protected  password 
(USER  PASSWRD). 


LOGOFF 

This  command  terminates  access  to  the  connected  system. 


LPRINT , LFN 

This  command  selects  the  N  on  Lue  NOVA/ECLIPSE  and  prints 
the  file  out  on  the  connected  system  printer. 


LPUNCH , LFN 

This  command  selects  the  LFN  on  the  NOVA/ECLIPSE  and 
punches  the  file  out  in  Hollerith  code  on  the  connected 
system  card  punch. 


SBATCH , SFN.SFPASSWRD, DISPOSITION, TERMINAL  ID 

This  command  selects  the  SFN  with  appropriate  SFPASSWRD  for 
execution  on  the  connected  system  in  the  batch  mode.  The 
output  of  the  file  (DISPOSITION)  and  location  (TERMINAL  ID) 
are  supplied  by  the  user. 
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LBATCH ,LFN , DI SPOS IT  I ON , TERMINAL  ID 

This  command  selects  the  LKN  on  the  NOVA/ECLIPSE  for 
execution  on  the  connected  system  in  the  batch  mode.  The 
DISPOSITION  and  TERMINAL  TD  are  supplied  by  the  user. 
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A .  Error  Handling 

There  are  four  general  types  of  errors  that  may  occur  in 
execution  of  the  program  MONITOR.  There  are  (a)  interpreter 
errors,  (b)  executive  function  errors,  (c)  NOVA/ECLIPSE  RDOS 
errors,  and  (d)  connected  computer  system  errors.  The  first  two 
types  are  errors  that  arise  within  the  MONITOR  software  itself. 
NOVA/ECLIPSE  RDOS  errors  occur  whenever  the  RDOS  generates  an 
error  condition,  and  the  last  type  of  errors  results  from 
operating  system  error  conditions  generated  by  the  connected 
computer  system. 

Connected  Commit  or  System  Errors.  MONITOR  was  desi  gned  to 
display  error  conditions  generated  by  the  connected  computer 
system  to  the  user.  Each  action  file  reserves  a  location  after 
the  control  character  "I"  for  op  to  two  expected  responses  from 
the  connected  system.  Any  response  not  matching  these  expected 
responses  is  displayed  to  the  user.  Thus,  any  crur  conditions 
of  the  connected  computer  system  are  simply  passed  to  the  user 
for  action.  Most  of  these  error  conditions  are  non-fatal  and 
do  nr‘  cause  MONITOR  to  fail.  However,  unexpected  results  may 
arise  if  error  conditions  are  encountered. 

NOVA  /  F.C1.T  PSE  RDOS  Errors .  MONITOR  executes  within  the 
direct  control  of  the  RDOS.  Error  conditions  generated  by  the 
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iTror  commit  ion  and  accumulator  values.  The  1’  DOS  Reference 
Manual  (Ref  9 :  F  - 1  -  F-2)  details  those  circumstances.  In  a  less 
severe,  but  fatal  error  condition,  the  RODS  will  halt  execution 
without  a  "panic."  Generally,  a  "Control  A"  input  will  restore 
the  Chi  to  the  user.  On  ether  occasions,  "Control  A"  will  have 
no  effect.  In  these  circumstances,  the  user  must  reset  the 
computer  and  bring  it  up  as  if  it  had  been  powered  down.  In  the 
best  case,  the  HDDS  error  condition  will  cause  an  automatic 
return  to  the  RDuS  Cl,  1  and  the  error  condition  will  be  displayed 
to  the  user.  In  any  case,  RDOS  error  conditions  are  generally 
symptomatic  of  software  errors  in  the  executing  program.  All 
such  error  conditions  should  be  examined  and  tracked  in  order  to 
correct  apparent  errors  in  the  source  code. 

MOKTTOK  Esecut  iv<?  Function  Errors.  Executive  function 
errors  are  closely  related  to  NOVA/ ECLIPSE  errors.  In  fact, 
those  errors  are  produced  by  the  RDOS,  but  arc  generally 
anticipated.  Thus,  such  errors  are  caught  by  the  MONITOR 
program  and  serviced  automatically,  or  a  specific  error 
condition  causes  a  software  halt  of  the  program.  For  example, 
whenever  a  FORTRAN  call  to  open  a  file  is  executed,  a  potential 
error  may  occur  that  indicates  that  the  file  is  already  open  or 
that  such  a  file  doesn't  exist.  MONITOR  handles  all  of  these 
types  of  errors  by  executing  a  STOP  and  displaying  the  cause  of 
the  stop.  Specifically,  if  the  CYBER  action  file  would  not  open 
properly  when  a  call  was  issued  to  open  it,  the  following 
message  would  be  displayed  for  the  user: 
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STOP 


CACT  NOT  01’ ON  ED  PROPERLY 


Other  executive  function  errors  are  handled  identically.  In 
each  instance,  the  cause  nest  be  isolated  before  program  MONITOR 
can  he  executed  successfully. 

MOKTTOR  IjtJgf  v_pretcr  Errors .  The  interpreter  errors  are 
those  that  the  interpreter  MONITOR . FR  anticipates  and  handles. 
Those  errors  are  handled  entirely  within  the  MONITOR  software. 
Whenever  such  as  error  occurs,  the  user  is  notified  via 
display,  and  a  prompt  is  given  to  indicate  that  a  connected 
input  is  needed.  Each  of  the  anticipated  error  conditions  and 
their  reasons  are  provided  be- low: 

INVALID  COMMAND  -■  EMPTY  STRING 

Indicates  that  a  command  string  is  comprised  cf  all  blanks 
or  nulls.  (Entering  a  carriage  return  alone  will  result  m 
this  error  condition.) 


SYNTAX  ERROR 

FIRST  OR  LAST  LITERAL  INVALID  SEPARATOR 

Indicates  a  command  string  began  with  a  comma  and/or  ended 
with  a  comma.  (Only  commas  and  spaces  are  separators. 
However,  commas  cannot  start  or  end  a  command  string. 
Spaces  are  ignored  except  between  other  literals.  Thus,  an 
entry  of  a  command  string  that  ends  with  a  comma  and  then  a 
space  will  result  in  this  error  condition.  NOTE:  Internal 
null  arguments  within  a  command  string  arc  allowed.  For 

ex  amp  1 e , 

PUT,, THIS  .THERE 

will  be  accepted  as  a  valid  string  with  the  command  TUT  and 
four  a  r g  umen t  s  .  ) 

INVALID  COMMAND  -  TOO  FEW  CHARACTERS 

Indicates  a  command  string  with  just  one  character.  Again, 
spaces  are  ignored  except  between  other  literals. 
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The 

i  mi  i  .•  t  . 

i  II  !  ■  t 


t  >•  ;  our  r  g  uineii  t  s  .  This 

woi  o  ;■  u p p  1  i. c; d  v<  i  t h  a 


invalid  command  - 


Each  cor  inn:.!  and  <  acii  nr.  i  i..  nt  may  he  up  to  30  characters 
long.  Th  i  s  i  r.ii  i  colt  a  n-i  a. and  or  argument  entered  was  31 

or  more  c  h  a r a c t  v r  s  . 


INVALID  COMMAND 

COMMAND  ROT  IN  ACTION  FILE 

or  supplied  not  equal  required  arguments 

Indicate:;  one  of  two  possibilities:  (1)  there  was  not  a 
match  of  the  command  entered  with  any  command  contained 
within  the  action  file.  (could  be  a  misspelling.)  (2)  the 
action  file  command  required  x  arguments  and  either  less 
than  x  or  more  titan  x  arguments  were  input.  (The  number  of 
arguments  must  be  exactly  as  specified  within  the  action 
file.) 


COMMAND  A PORT 

UNEXPECTED  ENTRY  IN  ACTION  TILE 

Indicates  an  undefined  or  nonexistent  control  character  set 
wiLhin  a  command  sequence.  (The  action  file  must  be 
corrected . ) 
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5  .  CYHKR  AcJ  ion  File  Pcs  i  g  n 

The  basic  structural  design  of  any  action  file  is  detailed 
in  the  main  body  of  this  report.  This  chapter  describes  the 
overall  design  of  action  files  and  details  the  design  of  the 
specific  CYDER  action  file  developed  and  implemented,  The 
listing  of  the  action  file  itself  is  in  Appendix  D. 

Essentially,  the  interpreter  initially  looks  for  the  first 
character  or  first  two  characters  of  each  line  in  the  action 
file.  Depending  upon  these  characters,  action  is  taken  to  read 
the  next  line,  stop  reading  the  file,  or  execute  a  line  just 
read.  Thus,  only  specific  characters  are  expected  in  the  first 
two  columns  of  the  action  file.  Any  other  characters  are  simply 
ignored.  If  no  recognizable  characters  or  no  characters  at  all 
are  in  columns  one  or  two ,  the  interpreter  cannot  find  any 
useful  information  and  aborts  reading.  This  feature  does  allot/, 
however,  comments  to  be  inserted  anywhere.  The  character  "C", 
for  example,  is  not  expected  by  the  interpreter.  Thus,  all 
lines  beginning  with  "C"  are  ignored  and  serve  as  comment  lines. 
Any  other  unexpected  character,  such  as  "A",  could  also  have 
been  used,  but  "C"  was  arbitrarily  chosen  to  match  with  FORTRAN 
comment  lines. 

Spacing  is  predetermined  by  the  expectation  of  the 
interpreter  as  well.  The  exact  spacing  established  is 
arbitrary,  but  once  established,  it  must  be  followed  explicitly. 
Thus,  columns  one  and  two  are  reserved  for  control  characters. 
Anything  may  be  in  the  rest  of  a  comment  line.  Lines  that  begin 
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with  "END."  and  "FINISH."  nay  have  comments  after  then,  as  the 
interpreter  will  simply  read  the  first  character  and  ignore  the 
remainder  of  the  line.  Each  command  sequence  starts  wi th  a 
period,  followed  by  the  name  of  a  particular  action  file.  Thus, 
for  the  CDC  CYBER,  each  sequence  starts  with  ".CACT"  .  This 
name  is  followed  by  a  specific  command,  as  indicated  in  Chapter 
3.  The  command  is  followed  by  the  exact  number  of  arguments 
required  in  the  form  of  a  shorpsign  and  an  accompanying  integer. 
Argument  three  is  #3,  for  example.  Each  of  these  entries  must 
be  separated  (arbitrarily)  by  commas.  As  mentioned  in  the  body 
of  this  report,  this  header  line  is  followed  by  executable 
statements  preceded  by  control  character  sets.  The  executable 
statements  must  (arbitrarily)  begin  in  column  nine.  (NOTE:  A  tab 
will  not  suffice  to  separate  the  control  character  sets  from  the 
executable  statements.)  In  each  executable  statement  that 
requires  an  argument,  the  exact  argument  parameter  from  the 
header  statement  must  be  used.  Thus,  if  an  executable  line 
requires  argument  three,  the  executable  line  must  contain  #3 
exactly  where  argument  three  is  required.  The  interpreter  will 
substitute  the  arguments  entered  by  the  user  into  the  specified 
locations.  As  noted  before,  each  command  sequence  ends  with  the 
keyword  "END."  .  and  the  entire  action  file  command  sequence 
ends  with  the  keyword  "FINISH."  . 

All  executable  statements  in  the  action  file  are  sent  to 
the  CYBER  for  execution  if  preceded  by  the  control  character 
set  VIS.  Thus,  these  statements  are  exactly  as  required  by  the 
CDC  CYBER.  Similar  requirements  must  be  met  for  other  action 
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files.  The  order  of  these  s  fat  orient  s  mist  also  be  acceptable  to 
the  connected  computer  system.  If  not  ir.  the  proper  order  or 
syntactically  incorrect,  the  CYBER  system  will  generate  error 
conditions  and  display  them  to  the  user.  Essentially,  the 
method  of  transferring  files  to  and  from  the  CYBER  utilizes  the 
command  execution  mode  of  the  CYBER  system.  In  this  mode,  the 
CYBER  always  responds  after  correct  user  input  with  "COMMAND-"  , 
and  this  is  indicated  in  the  action  file  response  line  —  the 
line  preceded  by  the  character  "I"  .  Up  to  two  expected 
responses  from  the  connected  system  may  be  in  the  line  after 
the  control  character  "I",  beginning  in  column  nine. 
Instructions  entered  in  the  command  sequences  for  PUT,  GET,  and 
similar  command  strings,  simply  tell  the  CYBER  to  copy  all  input 
to  a  file  name  or  copy  all  output  from  a  file  name.  The 
NOVA/ECLIPSE  access  ports,  when  connected  to  the  CYBER,  send  to 
the  input  file  and  receive  from  the  output  file.  To  terminate 
this  copying,  the  command  instruction  %EOF  is  issued.  All  other 
command  sequences  are  straightforward  and  detailed  in  the  CYBER 
user  documents. 

All  other  executable  statements  not  preceded  by  WS  tell  the 
NOVA/ECLIPSE  RDOS  to  do  something.  Most  are  straightforward  and 
all  are  explained  within  the  body  of  this  report.  The  lines 
preceded  by  WC  and  RC  contain  executable  statements  for  the  RDOS 
CLI.  For  example,  the  line  containing 

XFER/A  #1  QQVV/R 

is  a  CLI  instruction  to  transfer  the  ASCII  file  named  as 
user-supplied  argument  one  to  the  temporary  disk  file  QQVV ,  and 
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to  make  file  QQVV  a  random  file. 


Control  character  sets  RC  and 


W C  precede  these  kind  of  executable  lines,  causing  a  swap  to  the 
CLI  to  execute  these  instructions  and  then  a  swap  back  to  the 
main  interpreter  program.  Those  lines  that  are  blank,  except 
for  the  control  character  set,  have  no  statements  to  be  executed 
per  so.  The  MONITOR  software  proceeds  strictly  upon  the  basis 
of  the  control  sequence  read.  In  the  case  of  the  set  P.R ,  the 
interpreter  creates  a  temporary  file  on  the  NOVA/ F.CLIPSF.  disk 
that  v;  ill  be  used  by  a  subsequent  RC  statement.  Hence,  in  order 
for  the  command  sequence  to  execute  properly  from  start  to 
finish,  any  line  with  the  RR  control  character  set  must  be 
followed  by  a  line  with  the  RC  control  character  set.  The  RW 
character  set  indicates  that  a  carriage  return  needs  to  be  sent 
to  the  CYBER  to  initiate  access.  This  particular  command 
instruction  is  CYBER  system  dependent,  and  may  require  some 
modification  if  expected  to  be  used  with  another  connected 
computer  system.  The  entry  beginning  in  column  nine  after  the 
control  sot  WL  will  he  sent  verbatim  to  the  user  terminal  for 
display.  No  other  control  character  sets  have  been  established 
for  the  interpreter. 

It  should  be  noted  that  the  RDOS  console  interrupts  have 
not  been  deactivated  anywhere  within  the  software  developed. 
Thus,  the  console  interrupts  for  the  RDOS  CLI  are  effective  when 
executed  within  MONITOR.  For  example,  an  entry  by  the  user  that 
is  incorrect  may  be  totally  replaced  by  simply  entering  a 
backslash  "\"  .  The  next  keyboard  entry  will  begin  a  new  line. 
The  backspace  works,  and  the  "Control  A"  and  "Control  C"  inputs 
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work  as  well.  "Control  A"  and  "Control  C"  cause  the  currently 
executing  program,  such  as  MONITOR,  to  be  interrupted  and 
control  returned  to  the  RDOS  CLI.  "Control  C"  also  provides  a 
"Break"  file  that  displays  a  dump  of  memory  at  the  time  of  the 
interrupt . 

Finally,  the  action  file  for  the  CYBER  has  been  set  up  with 
the  following  results.  The  products  produced  upon  the  CYBER 
card  punch  and/or  printer  are  to  be  output  to  the  terminal 
located  in  the  AFIT  School  of  Engineering.  Further,  all 
products  may  be  picked  up  at  the  bin  labeled  "M/N"  ,  since  all 
output  products  will  be  tagged  with  the  banner  NEO.  The  NOVA 
terminal  identification  number  for  logging  in  purposes  is 
arbitrarily  set  at  777.  Lastly,  the  order  of  the  commands 
entered  into  the  action  file  is  based  upon  use.  Those  commands 
used  frequently  are  placed  in  the  action  file's  beginning, 
whereas  those  used  less  frequently  are  placed  later  in  the 
action  file.  Since  the  interpreter  searches  the  action  file 
sequentially  from  the  beginning  each  time  a  command  is  needed, 
those  used  more  often  will  be  found  in  less  time.  (NOTE:  The 
same  named  command  may  appear  more  than  once  within  an  action 
file.  Tn  order  for  the  interpreter  to  distinguish  one  command 
from  another,  in  this  case,  the  number  of  arguments  must  be 
different  for  each  command  name.) 


6 .  Sum mar  y 


The  instructions  and  guidelines  contained  within  this  user 
manual  arc  the  minimum  needed  to  operate  MONITOR.  Once  a  user 
becomes  familiar  with  the  action  files  and  interpreter,  many 
other  opportunities  may  occur  to  experiment  with  the  program 
MONITOR  that  would  alter  the  guidelines  set  forth  herein.  Such 
changes  are  expected  and  desirable,  if  this  command  language  is 
to  truly  be  general  purpose.  Furthermore,  there  may  be  areas  in 
which  even  the  basic  structure  of  the  interpreter  may  be 
profitably  altered.  See  the  recommendations  covered  in  Chapter 
V  of  the  main  report  for  some  potential  examples.  Finally,  the 
source  listings  and  interactive  guidelines  have  been  developed 
to  provide  the  user  with  necessary  instructions  governing 
MONITOR  execution.  Thus,  a  user  should  be  able  to  use  MONITOR 
quite  readily  with  only  a  listing  of  the  selected  action  file  to 
consult,  once  program  execution  has  begun. 
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Appendix  B 

Program  Descriptive  FJovcliart 
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START- 

MONITOR 


OPEN  ALL 
ACTION  FILLS 
CALL  LG IK 


CALL  PROMPT 


Fig  A.  MONITOH.FR  (Part  1) 
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Fig  ]].  PROMPT  .  SR 


AD-A100  019  AIR  FORCE  INST  OF  TECH  UMOHT-RATTERSON  AFB  OH  SCHOO— ETC  F/o  9/s 
CONSTRUCT, ON^.UNER.L  purpose  commano  LANOUAOE  FOR  USE  IN  C—  crci 

UNCLASSIFIED  AFIT/9CS/EE/60S-1S  „ 


Fig  13.  CNVRT.SR 
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REMOVE 
$TT01  & 
$TTI1 


I. 


c 


— N 
CALL 

TERMOP 


D 


Fig  14.  TOTERM.SR 


*  Return  to  a  specified  line  number  (602) 


Fig  15.  WRITSYSTM.FR 
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LOAD 

ELEMENT  OF 
ARRAY 


Fig  16.  WRSYS.SR 


Return  to  a  specified  line  number  (602) 


g  17.  WRITLOCAL.FR 


Fig  18.  READLWRITS.FR 


Fig  19.  RDAWR.SR 


Return  to  a  specified  line  number  (602) 


Fig  20.  READYREAD.FR 
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*  Return  to  a  specified  line  number  (602) 


Fig  21.  SENDFILE.FR 

I 


t 


Fig  22.  EXCLI.SR 
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Fig  23.  GETFILE.SR 
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Fig  24.  GETFILE.SR  (Part  2) 
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i 
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Fig  26.  TERMOP.SR  (Part  1) 
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COMPARE 
INPTR  TO 
OUTPTR 


Same? 


/  OUTPUT 
CHARACTER 
TO  $TTO 


INCREMENT 

OUTPTR 


/  Outpt>\  Ye  RESET 
equal  to  OUTPTR  TO 

Nmaxptr’/  BEGINNING 


STORE  HEW 
OUTPTR 


Fig  27.  TERMOP.SR  (Part  2) 
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Fig  2  9.  TERMOP.SR  (Part  4) 


Fig  30.  SYSIN.SR  (Part  1) 
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32.  SYSIN.SR  (Part  3) 
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G 


^  104 
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Appendix  C 

Load  inf  and  Exccut inn  MON  3  TOR 


Each  individual  routine  or  subroutine  created  for  the 
N0VA/F.CL1PSE  must  be  separately  compiled  or  assembled.  In 
accordance  with  the  RDOS  conventions,  all  assembly  language 
routines  have  been  given  the  file  name  extension  ".SR"  .  All 
FORTRAN  routines  have  been  given  the  file  name  extension  ".FR" 
.  For  example,  the  source  code  for  the  main  interpreter  program 
is  named  MONITOR. FR,  and  the  source  code  for  the  separate  task 
program  is  named  SYSIN.SR.  To  assemble  each  assembly  langauge 
source  program,  the  MACRO  assembler  was  used.  A  typical 
instruction  to  cause  assembly  follows: 

MAC  SYS  IN 

The  extension  is  not  needed,  since  the  assembler  automatically 
searches  for  the  file  name  with  the  extension  ".SR"  .  To 
compile  each  FORTRAN  language  source  program,  the  FORTRAN 
compiler  was  used.  A  typical  instruction  to  cause  compiling 
follows  : 

FORT  MONITOR 

The  extension  is  not  needed,  since  the  compiler  automatically 
searches  for  the  file  name  with  the  extension  ".FR"  .  The  local 
switch  "/ L"  (slash  and  L)  may  be  used  to  create  a  disk  file  to 
contain  the  assembled/compiled  results. 

The  RDOS  relocatable  loader  was  used  to  load  all  previously 
assembled  and  compiled  programs.  The  first  file  name  listed  in 
the  loader  instruction  sequence  becomes  the  executable  save 
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file.  All  such  files  are  given  the  file  name  extension  ".SV" 

The  local  switch  "/L"  may  be  used  to  create  a  disk  file  to 

contain  the  load  map  of  the  results.  The  following  string 

command  was  used  to  load  all  programs/ sources  that  constitute 

the  MONITOR  command  language  interpreter: 

RLDR/P/U  MONITOR  BGIN  PROMPT  REVERT  GETRSPS  CNVRT  ~ 
WRITSYSTM  WRSYS  WRITLOCAL  READLWRITS  RDAWR  SENDFILE  “ 

EXCLI  GETFILE  READYREAD  RECEVFILE  TOTERM  TERMOP  ~ 

SYS  IN  FMT.LB  FORT. LB  MINE5/L 

Once  executed,  file  MINES  contains  the  load  map  and  file 
MONITOR. SV  is  the  executable  binary  file.  The  local  switch  "/ P" 
causes  the  normal  relocatable  value  of  each  separate  binary 
file  to  be  printed  out  to  file  MINE5,  and  the  switch  "/U"  causes 
a  chain  of  undefined  symbols  to  be  maintained.  File  FORT. LB 
supplies  needed  FORTRAN  runtime  libraries  and  file  FMT.LB 
supplies  the  needed  multitasking  library.  The  order  and 
sequence  of  the  loader  command  is  as  specified  in  the  RDOS 
Reference  Manual  (Ref  9:D-6). 


Appendix  D 

Program  MONITOR  Source  Listrinr. 
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C - 

C - 

c 

c  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
c  +  + 

c  +  monitor.fr  + 

c  +  ****  CREATED  30  AUGUST  1980;  REV  01  ****  + 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

c 

c - 

C - 

c 

r  ic’k'k'k’kirk-k'kic 

c 

C  Program  MONITOR. FR  provides  a  simplified,  general  purpose 

C  Command  Language  for  use  in  computer  to  computer  dialog. 

C  The  host  system  is  a  Data  General  (DG)  NOVA  2/10  that  is 

C  connected  via  a  shared  disk  operating  system  to  a  DG 

C  ECLIPSE  S/250.  Via  a  standard  RS  232  modem  link,  this 

C  program  allows  intercommunication  to  any  compatible  computer 

C  system.  Hereafter,  the  NOVA/ECLIPSE  is  referred  to  as 

C  "local"  and  the  connected  computer  as  "system."  The 

C  program  was  initially  designed  for  intercommunication  with 

C  the  ASD  Control  Data  Corp  CYBER  750  as  the  "system." 

C 

C  MONITOR  serves  as  a  basic  command  string  interpreter.  Upon 

C  execution  of  MONITOR,  the  user  is  provided  instructions  on 

C  how  to  access  the  "system"  and  a  prompt  to  enter 

C  commands.  Command  structure  and  use  are  described  in  the 

C  MONITOR  Command  Language  User's  Manual. 

C 

C  "Local"  input  is  received  on  a  "local"  device  channel  -  $TT01 . 

C  "Local"  output  is  transmitted  on  device  channel  -  $TTI1 .  Via 

C  multitasking,  a  task  (SYSIN.SR)  is  always  monitoring  input 

C  while  another  task  (MONITOR. FR)  is  always  conducting  output. 

C  MONITOR  acts  as  the  executive  control  of  these  functions,  in 

C  addition  to  its  role  as  interpreter. 

C 

C  The  structure,  concept,  design,  and  implementation  of  program 

C  MONITOR  and  its  assorted  subroutines  are  detailed  in  the  thesis 

C  that  accompanied  the  development  -  AFIT/GCS/EE/80-2 . 

C 

c  ********** 

C 

c - 

c - 
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c 

C  **  Start  the  program  by  defining  tasks,  channels,  parameters,  ** 

C  etc.  CHANTASK  77,2  declares  that  up  to  77  distinct  channel 

C  numbers  may  be  used  in  the  program  and  that  2  asynchronous 

C  tasks  may  be  executing  "simultaneously." 

C 

CHANTASK  77,2 
C 

C  **  PARAMETER  MDIMl  is  the  size  of  the  one-dimensional  command  ** 

C  instruction  arrays.  MDIM2  is  the  size  of  the  one-dimensional 

C  argument  arrays  and  valid  instruction  string  array.  MDIM3 

C  is  the  size  of  the  one-dimensional  response  arrays. 

C 

PARAMETER  MDIMl  =  82,  MDIM2  =  30,  MDIM3  =  40 

**  SYSIN.SR  is  a  separately-compiled  assembly  language  program  ** 
that  serves  as  the  task  for  monitoring  all  "system"  input. 

DG  FORTRAN  requires  this  program  to  be  externally  defined  in 
the  calling  program  (MONITOR),  before  it  is  activated  via  a 
call  to  ITASK. 

EXTERNAL  SYS IN 

**  INPUT  is  the  initial  array  store  for  input  commands.  After  ** 
a  determination  of  the  command's  validity,  IACTFILE  is  the 
array  store  for  command  strings  read  from  the  action  file. 

Up  to  four  (4)  arguments  are  possible  with  any  single 
input  command,  and  the  arguments  are  stored  in  the  IARG 
arrays.  Up  to  two  (2)  separate  responses  from  the  "system" 
may  be  provided,  and  they  are  stored  in  the  IRSP  arrays. 

DIMENSION  INPUT(MDIMl),  IC0MMAND(MDIM2) ,  IARG1(MDIM2) 

DIMENSION  IARG2(MDIM2) ,  IARG3(MDIM2) ,  IARG4(MDIM2) 

DIMENSION  IACTFILE(MDIMl),  IRSP1(MDIM3) ,  IRSP2(MDIM3) 

**  Characters  used  for  comparisons  and  decisions  are  data  ** 

initialized.  Therefore,  they  must  be  declared  COMMON 
as  well.  The  data  are  mnemonic.  For  example,  KLTRW  is 
the  letter  "W"  and  KOMMA  is  a  . 

COMMON  /KONST/  KSPACE,  KSLSH ,  KOMMA 
COMMON  /KONST/  KUPAROW,  KLTRL ,  KLTRT 
COMMON  / KONST/  KNULL,  KPERIOD,  KLTRF 
COMMON  /KONST/  KLTRE,  KLTRC ,  KLTRW 
COMMON  /KONST/  KLTRR,  KSHARPSGN  .KLTRS 
COMMON  /KONST/  KNUM1 ,  KNUM2 ,  KNUH3 
COMMON  /KONST/  KNUM4 
C 

DATA  KSPACE, KSLSH, KOMMA/  "<40><40>", "<57><40>", "<54><40>"/ 

DATA  KUPAROW, KLTRL, KLTRT/  "<136><40>","<114><40>","<124><40>"/ 
DATA  KNULL, KPERIOD, KLTRF/  "<0><40>", "<56><40>", "<106><40>"/ 

DATA  KLTRE, KLTRC, KLTRW/  "<105X40>,’,"<103><40>","<127><40>"/ 
DATA  KLTRR, KSHARPSGN, KLTRS/  "<122><40>", "<43><40>", "<123><40>"/ 
DATA  KNUM1 ,KNUM2 ,KNUM3/  "<61 ><40>", "<62><40>", "<63><40>"/ 

DATA  KNUM4/  "<64X40 >"/ 
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C  **  DG  FORTRAN  allows  labels  to  be  tagged.  The  following  are  ** 

C  thus  defined: 

C 

ASSIGN  102  TO  IDOOVER 
ASSIGN  106  TO  IILGNUH 
ASSIGN  108  TO  I1C0NT 
ASSIGN  202  TO  IPROMPT 
ASSIGN  206  TO  IEND206 
ASSIGN  304  TO  ISYNERR 
ASSIGN  306  TO  IRMSTOR 
ASSIGN  404  TO  ILMSTOR 
ASSIGN  406  TO  I2CONT 
ASSIGN  412  TO  ICMDSTOR 
ASSIGN  420  TO  I1ARGSTOR 
ASSIGN  428  TO  I2ARGSTOR 
ASSIGN  436  TO  I3ARGSTOR 
ASSIGN  444  TO  I4ARGST0R 
ASSIGN  446  TO  ILGTHERR 
ASSIGN  502  TO  IEXAMFILE 
ASSIGN  506  TO  INOMOENTRY 
ASSIGN  508  TO  ICHKHDR 
ASSIGN  512  TO  I3CONT 
ASSIGN  602  TO  I4C0NT 
ASSIGN  606  TO  IEXECUTE 
ASSIGN  608  TO  ICHKSUBS 
ASSIGN  610  TO  ICONTCHK 
ASSIGN  614  TO  NRMSTOR 
ASSIGN  615  TO  I5CONT 
ASSIGN  702  TO  ITERMOP 
C 

C  **  BGIN.SR  opens  channels  21  and  22  for  "local"  input  and  ** 

output . 

CALL  BGIN 

**  The  various  possible  action  files  to  be  interpreted  are  ** 
opened  on  the  channels  indicated. 

CALL  OPEN  (1 ,"CACT",2,IEROR,82) 

IF  ( IEROR  .NE.  1)  STOP  CACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (2,"DACT",2, JER0R,82) 

IF  (JEROR  .NE.  1)  STOP  DACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (3 ,"VACT",2,KEROR,82) 

IF  (KEROR  .ME.  1)  STOP  VACT  NOT  OPENED  PROPERLY. 

CALL  OPEN  (4 , "MACT" , 2 ,LEROR ,82) 

IF  (LEROR  .NE.  1)  STOP  MACT  NOT  OPENED  PROPERLY. 
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TYPE  "The  Monitor  program  you  have  entered  provides  " 

TYPE  "intercommunication  between  the  NOVA/ ECLIPSE  computer" 
TYPE  "system  and  your  choice  of  another  system." 

TYPE  "  " 

TYPE  "  " 

C  IDOOVER  =  102 


TYPE 

"Please 

enter  the  digit 

opposite  the 

TYPE 

"you  des 

ire  to  use:  " 

TYPE 

ii  ii 

TYPE 

11 

1  — 

CDC  CYBER" 

TYPE 

II 

2  — 

DEC  10  " 

TYPE 

II 

3  — 

VAX  11/780  " 

TYPE 

ff 

4  — 

Your  own  " 

**  Call  the  program  PROMPT  to  signal  the  user  to 
provide  some  kind  of  terminal  entry. 

CALL  PROMPT 

**  Get  the  correct  action  file  requested  !>_,  the  user. 

READ  (11,104)  INTRY 
104  FORMAT  (II) 

IF  ( IK  TRY  .  I.E.  0  .OR.  INTRY  .GE.  5)  GO  TO  IILGNUM 
GO  TO  (1,2,3, 4)  INTRY 

IILGNUM  =  106 

106  TYPE  "You  have  entered  an  illegal  number.  Try  again!" 
GO  TO  IDOOVER 

1  TYPE  "You  have  selected  the  CYBER." 

GO  TO  I1C0NT 

2  TYPE  "You  have  selected  the  DEC." 

GO  TO  I1CONT 

3  TYPE  "You  have  selected  the  VAX." 

GO  TO  I1C0NT 

4  TYPE  "You  have  selected  your  own  file." 

GO  TO  I1CONT 


**  Once  the  desired  action  file  has  been  selected,  GETRSPS.FR  ** 
finds  the  action  file  and  stores  the  responses  to  be  sought 
from  the  "system"  from  this  point  forward. 

I1C0NT  =  108 

108  CALL  GETRSPS  ( INTRY, IRS PI , IRSP2, I1SSZ, I2SSZ) 

**  CNVRT.SR  converts  the  characters  stored  in  FORTRAN  format,  ** 
and  found  in  GETRSPS,  to  assembly  language  format.  It 
uses  the  same  arrays  and  also  returns  the  size  of  the 
C  response  arrays. 

C 

CALL  CNVRT  ( IRSP1 , IRSP2 , II SSZ , T2SSZ) 
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c 

c - 

c 

C  **  The  preliminaries  are  over  and  the  program  is  now  ready  ** 

C  for  user  instruction  inputs. 

C. 

TYPE  "Thank  you.  Please  enter  a  command." 

C 

C  **  ITASK  activates  task  SYS1N.SR  with  identity  number  ten  (10)  ** 
C  and  priority  one  (1).  Thus,  SYS1N  lias  lower  priority  than 

C  the  calling  program  -  Hull  I TOP .  MONITOR  has  priority  zero  (0) . 

C 

CALL  ITASK  (  SYS  IN ,  1 0 , 1  ,  IF.R  ,  1  ) 

IF  ( IER  .NE.  1)  STOP  SYSIN  NOT  ACTIVATED  PROPERLY. 

C 

C  **  Provide  the  user  with  the  prompt  ">"  .  ** 

C 

C  I PROMPT  =  202 
202  CALL  PROMPT 
C 

C  **  After  each  access  to  the  action  file,  its  pointer  needs  ** 

C  to  be  reset  to  the  file's  beginning.  The  call  to  FSEEK 

resets  the  pointer  accordingly. 

CALL  FSEEK  ( INTRY ,0) 

**  Read  what  the  user  inputs  and  store  in  INPUT.  Word  entries  ** 
may  be  separated  by  individual  commas  or  single  spaces. 

READ  (11,204)  (INPUT(I),  1=1,  MDIM1) 

204  FORMAT  (82A1) 

C 

C  **  Check  to  see  if  user  desires  terminal  only  operation  or  a  ** 

C  return  to  the  "local"  command  language  -  CLI .  An  input  of 

C  "~L"  reverts  user  to  the  "local"  CLI.  An  input  of  "~T" 

C  causes  terminal  only  operation. 

C 

DO  206  IKDXA  =  1  ,  HD  I  Ml 

IF  (INPUT(INDXA)  .NE.  KUPAROW  .OR.  INDXA  .GE.  MDIM1) 

+  GO  TO  IEND206 

INDXA  =  INDXA  +  1 

IF  (IMPUT( INDXA)  .EQ.  KLTRL)  CALL  REVERT 
IF  (INPUT( INDXA)  .EQ.  KLTRT )  GO  TO  ITERMOP 
INDXA  =  INDXA  -  1 

C  IEND206  =  206 
206  CONTINUE 
C 

C - 
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c 

C  **  Search  array  input  right  to  left  to  find  the  first  non-null/** 
C  non- blank  character. 

C 

DO  302  IKDXB  -  1,  H  1)1  Ml 

IF  (1NPUT( (MDIMl  +  1)  -  IKDXB)  .EO.  KOMMA) 

+  GO  TO  ISYKERR 

IF  ( 1  NPUT(  ( MDIM1  +  1)  -  IKDXB)  .ME.  KKL'LL  .AND. 

+  IMPL'T ( (MDIMl  +  1)  -  INDXB)  .NE.  KSPACE) 

+  GO  TO  IRMSTOR 

302  CONTINUE 
C 

C  **  If  none,  so  state  and  return  to  prompt.  ** 

C 

TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  -  EMPTY  STRING  *****" 

GO  TO  I PROMPT 
C 

C  **  If  the  string  ended  with  a  separator  comma,  so  state  ** 

C  and  return  to  the  prompt. 

ISYKERR  =304 
304  TYPE  "  " 

TYPE  "  *****  SYNTAX  ERROR  *****  " 

TYPE  "  *****  FIRST  OR  LAST  LITERAL  INVALID  SEPARATOR  *****  " 

GO  TO  IPROMFT 


**  Otherwise,  store  the  index  of  the  rightmost  character, 


IRMSTOR  =  306 

306  IRTMST1NDX  =  (MDIMl  *  1)  -  IKDXB 


C  Vs'*  Now  find  the  leftmost  character. 

C 

DO  402  INDXC  =  1,  MDIMl 

IF  (INPUT(IKDXC)  .EQ.  KOMMA)  GO  TO  ISYKERR 
IF  (INPUT( INDXC)  .NE.  KSPACE)  GO  TO  ILMSTOR 

402  CONTINUE 
C 

C  **  This  error  return  should  never  be  taken. 

C 

TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  -  EMPTY  STRING  *****" 

GO  TO  IPROMPT 
C 

C  **  Discard  initial  blanks/spaces  and  store  it. 

C 

C  ILMSTOR  =  404 

404  LTMOSTINDX  =  INDXC 
C 
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c 

c 


Check  for  obvious  error  condition. 


• k-k 


IF  ( LTHOSTI h'DX  . NE .  IRTHSTINDX)  CO  TO  12C0NT 
C 

TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  -  TOO  FEW  CHARACTERS  *****  " 

CO  TO  I PROMPT 
C 

C  **  Now  search  the  input  string  for  the  command  portion,  j.e.,  ** 

C  until  a  separator  or  a  rightmost  character  is  encountered. 

C 

C  I2CONT  =406 

40b  DO  408  INDXD  =  LTMOSTINDX,  IUTHSTINDX 

IF  (IKPUT(  INDXD)  . F.Q.  KSPACE  .OR.  INPUT(  INDXD)  .EQ. 

-f  KOMMA)  CO  TO  ICMDSTOR 

408  CONTINUE 
C 

C  **  If  the  string  is  a  single  command,  store  it  in  COMMAND.  ** 

C  First,  initialize  index  for  the  COMMAND  array. 

C 

NDIM1  =  (IRTMST1NDX  -  LTMOSTINDX)  +  1 
IF  (NDIM1  .GT.  MDIM2)  GO  TO  1 1. GTE ERR 
DO  410  IKDXE  =  1,  NDIM1 

ICOMMAND(INDXE)  =  IKrUTQnDXE  +  (LTMOSTINDX  -  1)) 

410  CONTINUE 

**  At  each  point  that  the  number  of  arguments  is  determined,  ** 
jump  ahead  to  execute  the  command.  In  this  case,  for  example, 
there  is  just  a  command  word  and  no  arguments. 


NUMARGS  =  0 
GO  TO  IEXA11FILE 
C 

c 

C  **  A  separator  was  encountered,  so  there  is  more  than  just  a 
C  single  command.  Store  the  command  portion  and  resolve  the 

C  rest  of  the  string. 

C 

C  ICMDSTOR  =  412 

412  ND1M1  =  INDXD  -  LTMOSTINDX 

IF  ( NDIM1  .GT.  MD1M2)  GO  TO  ILGTIIERR 
DO  414  1NDXF  =  1,  ND1M1 

I COMMAND ( INDXF )  =  INFUT(INDXF  +  (LTMOSTINDX  -  1)) 

414  CONTINUE 
C 

C  **  Proceed  to  establish  the  value  of  the  first  argument. 

C 

IDXP1  =  INDXD  +  1 

DO  416  INDXG  =  1DXP1  ,  IRTHSTINDX 

IF  (INPUT(INDXG)  .F.Q.  KSPACE  .OR.  INPUT(INDXG)  .EQ. 
+  KOMMA)  GO  TO  IlARGSTOR 

416  CONTINUE 
C 
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C  **  If  a  single  argument,  process  it. 

C 

NDIM2  =  IRTMSTINDX  -  INDXD 
IF  (NDIM2  .GT.  MDIM2)  GO  TO  1LGTHERR 
DO  418  INDXH  =  1 ,  NDIM2 

1ARG1  (  INDXH )  =  lf!PUT(  11,'DXH  +  INDXD) 

418  CONTINUE 
C 
C 

NUMARGS  =  1 
GO  TO  IEXAMF1LE 
C 
C 

**  A  separator  was  encountered.  Store  the  first  argument 
portion  and  resolve  the  rest  of  the  string. 

I1ARGST0R  =  420 

420  NDIM2  =  INDXG  -  (INDXD  +  1) 

IF  (NDIK2  .GT.  MDIM2 )  CO  TO  ILCTUERR 
DO  422  IKDXI  =  1,  NDM2 

IARGI(INDXI)  =  INPUT( IKDXI  +  INDXD) 

422  CONTINUE 

**  Proceed  to  get  the  next  argument  for  array  2. 

IGXP1  =  INDXG  +  1 
DO  424  IN’DXJ  =  IGXP1  ,  IRTHSTINDX 

IF  (INPUT(INDXJ)  .EQ.  KSPACE  .OR.  INPUT(INDXJ)  .EQ. 
+  KOMMA)  GO  TO  I2ARGSTOR 

424  CONTINUE 

**  Just  two  arguments  -  process  the  second. 

NDIN3  =  IRTMSTINDX  -  INDXG 
IF  (NDIH3  .GT.  MDI.M2)  GO  TO  ILGTUERR 
DO  426  1NDXK  =  1,  NDIH3 

IARG2( INDXK)  =  INPUT(INDXK  +  INDXG) 

426  CONTINUE 


NUMARGS  =  2 
GO  TO  IEXAMFILE 

**  A  separator  was  encountered.  Store  the  second  argument  ** 
portion  and  resolve  the  rest  of  the  string. 

I2ARGST0R  =  428 

428  NDIM3  =  INDXJ  -  (INDXG  +  1) 

IF  (NDIH3  .GT.  MD1M2)  GO  TO  ILGTUERR 
DO  430  INDXL  =  1,  NDIM3 

IARG2( INDXL)  =  INPUT( INDXL  +  INDXG) 

430  CONTINUE 
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C  **  Frocede  to  get  the  next  argument  for  array  3. 

C 

1JXP1  -  INDXJ  +  1 

DO  432  INDXM  =  IJXP1  ,  IRTMSTINDX 

IF  (INPUT( INDXM)  . F.Q.  KSPACE  .OR.  INPUT(IWDXM)  .EQ. 
+  KOMMA)  00  TO  13ARGST0R 

432  CONTINUE 
C 

C  **  Just  three  arguments  -  process  the  third. 

C 

NDIM4  =  IRTMSTINDX  -  INDXJ 
IF  (NDIM4  .GT.  MDIM2)  GO  TO  1IGTHERR 
DO  434  INDXN  --  1  ,  ND1M4 

IARG3(  1MDXN)  IKPUT( INDXN  +  INDXJ) 

434  CONTINUE 
C 

c 

NU MARGE  =  3 
GO  TO  IEXAMFILE 
C 
C 

C  **  A  separator  was  encountered.  Store  the  third  argument 
C  and  resolve  the  rest  of  the  string. 

C 

C  I3ARGST0R  =  436 

436  NDIM4  =  INDXM  -  (INDXJ  +  1) 

IF  (IJDTM4  .GT.  MDIM2)  GO  TO  ILGTHERR 
DO  438  INDXO  -  1,  NDIM4 

IARG3 ( INDXO)  =  INPUT( INDXO  +  INDXJ) 

438  CONTINUE 
C 

**  Procede  to  get  the  next  argument  for  array  4. 

IMXPl  INDXM  +  1 
DO  440  INDXP  =  IMXPl,  IRTMSTINDX 

IF  ( IN'PUTC  INDXP)  .EQ.  KSPACE  .OR.  INPUT(INDXP)  .EQ. 
+  KOMMA)  GO  TO  I4ARGST0R 

440  CONTINUE 


**  Just  four  arguments  -  process  the  fourth. 

NDIM3  =  IRTMSTINDX  -  INDXM 
IF  (NDIK5  .GT.  MDIM2 )  GO  TO  II  ,  "’ERR 
DO  442  INDXQ  =  1,  NDIM5 

IARG4( INDXQ)  =  INPUT( INDXQ  +  INDXM) 

442  CONTINUE 


NUMARGS  =  4 
GO  TO  IEXAMFILE 
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C  **  A  separator  was  encountered.  There  are  too  many  arguments.  ** 
C  Give  an  error  message  and  return  to  the  prompt. 

C 

C  I4ARGST0R  =  444 
444  TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  -  TOO  MANY  ARGUMENTS  *****" 

GO  TO  I PROMPT 
C 

C  I LG TH ERR  =  446 
446  TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  -  TOO  MANY  CHARACTERS  *****  " 

GO  TO  I PROMPT 


**  Once  a  potentially  valid  command  string  has  been  accepted,  ** 
it  is  time  to  examine  the  action  file  for  that  command. 

The  strings  of  the  action  file  are  read  into  IACTFILE. 

IEXAMFILE  =  502 

502  READ  (  INTRY ,  504)  ( IACTFII.E(  J)  ,  J  =  1,  MDIM1) 

504  FORMAT  (S2A1) 

**  Check  the  first  character  of  the  line  just  read.  ** 

If  an  "F",  there  are  no  more  entries  to  read.  If  a 
period,  then  the  encountered  header  line  needs  to  be  checked. 

IF  (IACTFILE(l)  .EQ.  KLTRF)  GO  TO  INOMOENTRY 
IF  (IACTFILE(l)  .EQ.  KPERIOD)  GO  TO  ICHKHDR 
GO  TO  IEXAMFILE 

INOMOENTRY  =  506 
506  TYPE  "  " 

TYPE  "  *****  INVALID  COMMAND  *****  " 

TYPE  "  *****  COMMAND  NOT  IN  ACTION  FILE  *****  " 

TYPE  "  *****  OR  SUPPLIED  NOT  EQUAL  REQUIRED  ARGUMENTS  *****  " 
GO  TO  IPROMPT 
C 

C  **  All  commands  are  ten  (10)  characters  or  less.  Here,  ** 

C  the  command  portion  of  the  header  is  determined. 

C 

C  ICHKHDR  =  508 

508  DO  510  INDXZ  =  7,  17 

IF  (IACTFILE( INDXZ)  .EQ.  KSPACE  .OR. 

+  IACTFILE( INDXZ)  .EQ.  KOMMA)  GO  TO  I3CONT 

510  CONTINUE 
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C  **  Compare  the  header  command  to  that  input  by  the  user.  ** 

C  If  correct,  proceed.  Otherwise,  return  to  read  the  action 

C  file  again  until  finished,  or  the  next  header  is  encountered. 

C 

C  13C0NT  =  ^1 2 

512  INDXY  =  INDXZ  -  7 
C 

IF  (NDIM1  .NE.  INDXY)  GO  TO  IEXAMFILE 
DO  514  INDXX  =  1,  INDXY 

IF  (IACTFIEE( INDXX  +6)  .NE.  ICOMMAND( INDXX) ) 

+  GO  TO  IEXAMFILE 

514  CONTINUE 

**  Look  at  the  number  of  required  arguments  for  this  command.  ** 

If  there  are  no  arguments,  then  two  spaces  after  the 
command  string  in  the  header  will  be  a  space.  Similarly, 
if  there  is  one  argument,  five  spaces  after  the  command  string 
in  the  header  will  be  a  space,  and  so  forth.  The  INDX 
numbers  are  the  location  of  the  sharpsigns  in  the  header 
string.  Compare  the  command  string  in  IACTFILE  with  the 
sharpsign  location  to  determine  how  many  arguments  are  required. 

INDX1  =  INDXZ  +  1  ;The  sharpsign  is  2.5,8, 

INDX2  =  INDXZ  +  4  ;and  11  spaces  after  command 

INDX3  =  INDXZ  +  7  ; string  -  1,4,7,  or  10  spaces 

INDX4  =  INDXZ  +  10  ; after  comma,  if  arguments  exist 

NNUMARGS  =  4 

IF  ( IACTFILE ( INDX4)  .EQ.  KSPACE)  NNUMARGS  =  3 

IF  ( IACTFILE( INDX3 )  .EQ.  KSPACE)  NNUMARGS  =  2 

IF  ( IACTFILE( INDX2)  .EQ.  KSPACE)  NNUMARGS  =  1 

IF  (IACTFILE(INDXI)  .EQ.  KSPACE)  NNUMARGS  =  0 

**  Compare  the  required  number  of  arguments  with  the  supplied  ** 
number  of  arguments. 

IF  (NUMARCS  .EQ.  NNUMARGS)  GO  TO  14C0NT 

**  If  the  arguments  supplied  are  not  equal  the  number  required,** 
then  continue  to  examine  the  action  file  for  the  same  named 
command  with  the  appropriate  number  of  arguments.  (NOTE:  This 
means  that  more  than  one  command  with  the  same  name  may  be  entered 
and  found  within  the  action  file,  but  each  must  have  a  different 
number  of  arguments.) 

GO  TO  IEXAMFILE 
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C  **  If  argument s  required  equal  ,ir;;inr.i  its  supplied,  then  read  ** 

C  the  next  line  in  the  action  file,  v.'hich  is  the  first  cottmand 

C  in  the  command  sequence.  The  last  command  in  the  sequence 

C  precedes  "END."  . 

C 

C  I4C0NT  =  602 

602  READ(  IKTRY ,604)  ( IACTFII.E(K)  ,  K  =  1,  MD1M1 ) 

604  FORMAT  (82A1) 

C 

C  **  Look  at  the  first  two  control  letters  to  determine  ** 

C  specific  actions  to  take.  If  "END."  is  encountered,  the  command 

C  sequence  is  over.  If  an  "S"  or  "C"  is  encountered  in  column 

C  two  (2),  then  the  string  needs  to  be  checked  for  substitution 

C  of  arguments  for  the  sharpsigns  in  the  action  file.  Then  the 

C  remaining  control  letters  are  examined.  Appropriate  subroutines 

C  are  called  to  execute  the  strings  as  required.  Each  subroutine 

C  returns  to  the  place  whore  a  new  line  out  of  the  action  file 

C  may  be  read  and  examined.  For  further  discussion  of  control 

C  characters,  look  at  the  action  file  documentation  or  the 

C  MONITOR  Command  Language  User's  Manual. 

C 

IF  (lACTFILE(l)  .EQ.  KLTRE)  CO  TO  1PR0MPT 

IF  ( IACTF1LE(  2 )  .  F.Q .  KLTKS  .OR.  IACTF1LE(2)  .EQ.  KLTRC) 

+  CO  TO  ICI1KSUKS 
C  IEXECUTE  =  606 

606  IF  (IACTFIl.F.(l)  .EQ.  KLTitW  .AND.  IACTFILE(2)  .EQ.  KLTRS) 

+  CALL  WRITSYSTM  ( IACTFILE,  NRTMSTINDX  ,  $602 ) 

IF  (IACTFILE(I)  .EQ.  KLTP.W  .AND.  IACTF1LE(2)  .EQ.  KLTRL ) 

+  CALL  WRITL0CAL  ( IACTFILE, MDIN1  ,  $602) 

IF  (IACTFILE(I)  .EQ.  KLTRR  .AND .  IACTFILE(2)  .EQ.  KLTRW ) 

+  CALL  READLWRITS  ($602) 

IF  (IACTFILE(I)  .EQ.  KLTRU  .AND.  IACTFILE(2)  .EQ.  KLTRC) 

+  CALL  SEND!' ILK  (  IACTFILE,  MD1  Ml  ,  $602) 

IF  (IACTFII.E(I)  .F.Q.  KLTRR  .AND.  IACTFILE(2)  .EQ.  KLTRC) 

+  CALL  RECEVF1LE  ( IACTFILE , MD1M1 , $602 ) 

IF  (IACTFILE(l)  .F.Q.  KLTRR  .AND.  IACTFILE(2)  .EQ.  KLTRR) 

+  CALL  READYKEAD  ($602) 

C 

C  **  If  unexpected  letters  are  encountered,  the  action  file  is  ** 

C  suspect.  Abort  and  try  again. 

C 

TYPE  "  " 

TYPE  "  *****  COMMAND  ABORT  *****  " 

TYPE  "  *****  UNEXPECTED  ENTRY  IN  ACTION  FILE  *****  " 

GO  TO  I PROMPT 
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c 

C  **  Check  for  and  make  any  required  substitutions.  ** 

ICHkSUBS  =  608 
608  IBG1N1NDX  =  9 

**  Start  looking  in  column  nine  (9)  for  sharpsigns  to  replace.  ** 
Then  use  now  value  of  IBGIN1NDX  on  subsequent  iterations. 

ICOUTCHK  =610 

610  DO  612  NAINDX  =  1BGININDX,  MD1M1 

IF  (IACTF1LE( NAINDX)  .EQ.  KSHARPSGN)  GO  TO  I5C0NT 

612  CONTINUE 

**  There  were  no  sharp  signs  or  there  are  no  more  sharp  signs.  ** 
Now  find  the  rightmost  index  of  the  current  command  line 
and  return  to  execute  string. 

DO  613  NCINDX  =  1,  MDIM1 

IF  ( IACTFILE  ((  MD1M1  +  1)  -  NCINDX)  . NE .  KNULL  .AND. 

+  IACTFILE  ((  MDIM1  +  1)  -  NCINDX)  .NE.  KSPACE) 

+  GO  TO  NRHSTOR 

613  CONTINUE 

NRMSTOR  =614 

614  NRTMSTINDX  =  (UDIMl  +  1)  -  NCINDX 
C 

GO  TO  IEXECUTE 
C 

C  **  Collapse  the  array  about  the  sharp  signs.  ** 

C 

C  I5CONT  =  615 

615  NAP1INDX  =  HAINDX  +  1 
NAM1INDX  =  NAINDX  -  1 

IF  (IACTFILE(NAPIINDX)  .EQ.  KNUM1)  IVALOFSGN  =  1 

IF  (IACTFILE(NAPIIHDX)  .EQ.  KNUM2 )  IVALOFSGN  =  2 

IF  (lACTFILK(NAPlINDX)  .EQ.  KNUH3)  IVALOFSGN  =  3 

IF  (IACTFILE(NAPIINDX)  .EQ.  KNUM4)  IVALOFSGN  =  4 

M2MDIM1  =  HD IMl  -  2 
DO  616  NBINDX  =  NAINDX,  M2MDIM1 

IACTFILE ( N  B 1 KDX )  =  IACTFILE( NBINDX  +2) 

616  CONTINUE 
C 
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C  **  Determine  the  size  of  the  argument  arr  iys  (IARG)  and  expand  ** 
C  the  command  sequence  in  1ACTFILE  to  make  room  for  the 

C  substitution  of  the  IARG  arrays,  where  the  corresponding 

C  sharpsigns  had  been.  IVALOFSGN  is  the  value  of  the  particular 

C  sharpsign  being  substituted  with  IARG. 

C 

GO  TO  (618,620 ,622 ,624)  ,  IVALOFSGN 
C 

618  ISIZEARG  =  NDIM2 
GO  TO  626 

620  ISIZEARG  =  NDIM3 
GO  TO  626 

622  ISIZEARG  =  NDIM4 
GO  TO  626 

624  ISIZEARG  =  NDIM5 
C 

C  **  Expand  the  array  to  make  room  for  the  substitution  of  IARG.  ** 
C 

626  IRGHTMST  =  MDIM1  -  ISIZEARG 
IKCRMAX  =  IRGHTMST  -  NAINDX 

IACTFILE( IRGHTKST  +  ISIZEARG)  =  IACTF1LE( IRGHTMST) 

DO  628  Ml  =  1 ,  IKCRMAX 

IACTFILE(( IRGHTMST  -  Ml)  +  ISIZEARG)  = 

+  IACTFILE( IRGHTMST  -  Ml) 

628  CONTINUE 


C 

C 

c 

c 


c 


c 


c 


c 


**  Replace  each  sharp  sign  —  #1,  #2,  #3,  and  #4 

GO  TO  (630,634,638,642),  IVALOFSGN 

630  DO  632  M2  =  1,  ISIZEARG 

IACTFILE(NAMl 1NDX  +  M2)  =  IARG1(M2) 

632  CONTINUE 
GO  TO  646 

634  DO  636  M3  =  1,  ISIZEARG 

IACTFILE(NAM1 INDX  +  M3)  =  IARG 2 (M3 ) 

636  CONTINUE 
GO  TO  646 

638  DO  640  M4  =  1,  ISIZEARG 

IACTFILE(NAM1INDX  +  M4)  =  IARG3(M4) 

640  CONTINUE 
GO  TO  646 

642  DO  644  M5  =  1 ,  ISIZEARG 

IACTFILE( NAMl INDX  +  M5)  =  IARG4(M5) 

644  CONTINUE 

**  Recalculate  IBGININDX  for  the  next  iteration. 
646  IBGININDX  =  NAINDX  +  ISIZEARG 
GO  TO  IC0NTCHK 


if  used. 


** 


** 
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c 

c - 

c 

C  **  Before  going  to  the  terminal  operation  mode,  inactivate 
C  (kill)  the  task  SYS1N.  Then  call  the  program  TOTERM.SR, 

C  which  removes  defined  device  codes  utilized  within  SYS III . 

C 

C  ITERMOP  =  702 

702  CALL  AKlLL(l) 

C 

CALL  TOTERM 


C 


** 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


STOP  END  OF  THE  PROGRAM 
END 


+  +  +  +  +  +  +  +  +  •*+  +  +  +  +  +  •»•»+  +  +  +  +  +  +  +  + 


END  110NIT0Pv.FR 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


12? 


44444444444444444444444444 

4 


4  BGIN.SR  + 

4  ****  CREATED  3  JULY  1980;  REV  01  ****  4 

4  4 

444444444444444444444444444 


kk  k  *  kk  k  k  k  k 

Program  BGIN.SR  is  called  from  MONITOR. FR  and  returns  to 
MONITOR.  It  is  called  at  the  beginning  of  the  MONITOR  program 
to  open  devices  $TTO  and  $TT1  for  all  subsequent  programs. 
There  are  no  arguments  or  parameters  that  are  passed  via  BGIN. 

k  k  kkkk  k  kkk 


TITL 

BGIN 

; Program  name  -  Begin 

ENT  ] 

BGIN 

;Enables  outside  entry  into  this 
; program 

TXTM 

1 

;Packs  ASCII  strings  left  to  right 

EXTU 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

EXTN 

.1 

;Provides  some  FORTRAN  initialization 

•NREL  ;Normal  relocatable  space  starts 

FS. 


1  23 


BEGIN  TO  OPEN  DEVICES 


EGIN  : 
START: 


JSR  @  .FARL 

SUB  1,1 

;Load 

default  mask 

LDA  0,  NTTO 

;Lo.'id 

bytopointer  to  $TTO 

.SYSTM 
.OPEN  21 

;Open 

$TTO  on  channel  21 

JMP  ERROR 

LDA  0,  NTT I 

;Load 

bytcpointer  to  $TTI 

.SYSTM 
.OPEN  22 

JMP  ERROR 

;  Open 

$TTI  on  channel  22 

JMP  RT 

;  Jump 

to  return  location  when 

complete 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERROR:  . SYSTM 

.EUTN  -.Abnormal  return  -  error 

JMP  ERROR 

;  BYTEPOINTERS  DEFINED 


NTTO: 

.  +  1*2 

.TXT  "$TTO" 

;Bytcpointer 

to  device 

$TTO 

NTT  I: 

.  +  1*2 

.TXT  "$TTI " 

;Bytepointcr 

to  device 

$TTI 

RT:  JSR  0  .FRET 

FS.=0 

TMP=-167 

.END  BG1N 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+ 

+  END  BG1N.SR 

♦ 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+ 


+ 

+ 

+ 

+ 

+ 


1 
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+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+ 

+  PROMPT. SR 

+  ****  CREATED  3  JULY  1980;  REV  01  **** 

+ 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+ 

+ 

+ 

+ 

+ 

+ 


**  ******** 

Program  PROMPT. SR  is  called  from  MONITOR. FR  and  returns  to 
MONITOR.  It  is  called  several  times  within  MONITOR,  each  time 
to  provide  the  user  a  prompt  that  information  may  be  entered. 

The  prompt  character  for  MONITOR  is  ">"  .  There  are  no  arguments 
or  parameters  that  are  passed  via  PROMPT. 

********** 


.TITL  PROMPT 
.ENT  PROMPT 

.  TXTM  1 
.  EXTU 

. EXTN  .1 


;  Program  name  -  Prompt 

;Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

;Provides  some  FORTRAN  initialization 


•NREL  ;Normal  relocatable  space  starts 

FS. 
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write  pko::pt  to  $tto 


PROMPT: 

JSR  @  .FARE 

START: 

SUB  1  ,  1 

;I,oad  default  mask 

LDA  0,  PRMT 
. SYSTM 

{Load  bytepointer  to  prompt 

.WRL  21 

JMP  ERROR 

{Write  prompt  to  channel  21 

JMP  RT 

{Jump  to  return  location  when  complete 

ROUTINE  TO  RETURN  TO  THE  CM  ABNORMALLY 


ERROR :  . SYPTM 

.  KRTN 
JMT  K!;Rf  R 

BYTLPOI  NTi  i:  I'EP  I  M ’> 


frmt: 


.  +  1-2 

.TXT  "><1 j'" 


{Abnormal  return  -  error 


{Bytepointer  to  prompt  -  >  (with 
{carriage  return) 


RT:  J  SR  0  .FRET 


KS .  =0 
TMP=-1G7 


.END  PROMPT 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  PROMPT. SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


A 
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+  +  +  +  +  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  +  +  +  + 


+  4- 

4-  REVERT .  SR  4- 

+  ****  CREATED  15  JULY  1980;  REV  01  ****  4- 

4-  4- 


+  +  +  +  +  +  +  +  +  +  +  4-4*4-  +  4-  +  +  +  4-4-  +  +  4-  +  4-  + 


kkkk  k  k  •.'/  k  -k  'k 

Program  RLVr.RT.SR  is  called  Iron  MONITOR. FR  and  always  returns 
to  Lie  "Iccal"  CLI.  This  program  is  called  by  the  user  entering 
"~L"  anywhere  in  the  line  that  follows  a  prompt.  There  are  no 
parameters  or  arguments  that  are  passed  via  REVERT. 

*  kk  kk  k  k  k  k  k 


. TITl.  REVERT 
.ENT  REVERT 

. TXTM  1 
.  EXTU 

.  EXTN  .1 


; Program  name  -  Revert  to  CLI 

;Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

;Provides  some  FORTRAN  initialization 


.NREL  ;Normal  relocatable  space  starts 

FS. 
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NOTIFY  USER  OF  RKTURN  TO  CLI 


REVERT:  JSR  Q  .FAUN 

SUB  1,  1 
LDA  0,  NOT;'. A 
. SYSTM 
.  WRI .  21 
JUP  ERROR 

;  ROUTINE  FOR  NORMAL  RETURN  TO  THE  CLI 


START:  .SYSTM 

.RTH  ;Normal  return  -  no  error 

JKP  ERROR 

JUP  RT  ;Juinp  to  return  location  when  couple 

:  ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERROR:  .SYSTM 

. ERTN  ;Abnormal  return  -  error 

JMP  ERROR 

;  BYTEPOINTER  DEFINED 


NOTEA:  .  +  1*2  ;Bytepointer  to  message  (NOTEA) 

•TXT  "You  have  returned  to  the  local  CLI  mode.<15>" 


RT:  JSR  (?  .FRET 

FS.=0 

TMP=-167 


;Load  default  mask 

;Load  bytepointer  to  message 

iWrite  message  to  channel  21  ($TTO) 


END  REVERT 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


+ 

+ 

+ 


+ 

getrsps.fr  + 

****  CREATED  8  AUGUST  1980;  REV  00  ****  + 

+ 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


Program  GETRSPS.FR  is  called  by  MONITOR. FR  and  returns  to 
MONITOR.  Its  sole  function  is  to  read  the  selected  action  file 
(seeking  that  lino  that  begins  with  the  control  character  "I"  in 
column  one  (1))  and  store  up  to  two  (2)  possible  responses  that 
are  expected  from  the  "system"  when  intercommunication  is  taking 
place . 

The  call  to  GETRSPS  is  as  follows: 

CALL  GETRSPS  ( INTRY , IRSP1 , IRSP2 , I1SSZ , I2SSZ) 

(Integer)  INTRY  is  the  user  inputed  channel  number  of  the 
selected  action  file  and  is  the  only  parameter  passed  from 
MONITOR  to  GETRSPS.  The  remaining  parameters  are  returned  from 
GETRSPS  to  MONITOR.  They  are: 

IRSP1  -  one-dimensional  array  containing  first  response, 
if  any 

IRSP2  -  same  for  second  response,  if  any 
I1SSZ  -  integer  that  indicates  size  of  IRSP1 
I2SSZ  -  same  for  IRSP2 

'k'ic'k'k'k-k'k'k'k'ic 
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o  o  o  o 


c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 


**  PARAHERTER  MDIMl  is  the  size  of  the  one- d  i  mens  i  ona  1  command  ** 
sequence  array.  MDIM3  is  the  size  of  the  one-dimensional 
response  arrays. 

PARAMETER  MDIMl  =  82,  MDIM3  =  40 

**  GETRSPS  receives  an  input  channel  and  returns  the  first  and  ** 
second  responses  (if  any),  as  well  as  their  sizes. 

SUBROUTINE  GETRSPS  ( INCHAN, 1 1STRSP , I2NDRSP , I 1STSZ , I2NDSZ) 

**  IINITAR  is  an  initialized  array  that  stores  the  command  ** 
sequence  line  as  read  from  the  action  file.  It  parallels  the 
use  of  I.ACTFILE  in  MONITOR. 

DIMENSION  IlNITAR(KDIMl),  I1STRSP(MDIM3) ,  I2NDRSP( MDIM3 ) 

**  Characters  used  for  comparisons  and  decisions  are  data-  ** 

initialized.  They  must  therefore  be  declared  COMMON. 

COMMON  /IK ON ST/  KLTRI ,  KSPACE,  KOMMA 

DATA  KLTRI, KSPACE, KOMMA/  "<111><40>", "<40><40>", "<54><40>"/ 

**  Since  the  response  arrays  may  be  empty,  they  must  be  ** 

cleared.  Then,  if  no  responses  are  provided,  the  expected 
response  will  be  blanks  or  spaces  by  default. 


DO  1002  JJ  =  1,  MDIM3 

IISTRSP(JJ)  =  KSPACE 
I2NDRSP(JJ)  =  KSPACE 

1002  CONTINUE 
C 

C  **  Read  a  line  out  of  the  action  file  and  begin  search. 
C 

1004  READ  (INCHAN, 1006)  (IINITAR(II) ,  II  =  1,  MDIMl) 

1006  FORMAT  (82A1) 

C 
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C  **  If  the  control  character  "£"  is  not  encountered,  read  the  ** 
C  next  line  of  the  action  file  until  such  a  line  is  encountered . 

C  (NOTH:  Each  action  file  must  have  a  line  with  control 

C  character  "I"  or  GETRSl’S  will  generate  on  error  condition.) 

C  When  the  desired  line  is  encounter* d ,  begin  searching  for  a 

C  response  in  column  nine  (9)  and  beyond.  If  nothing  is  there, 

C  return  to  the  calling  program.  If  a  separator  comma  is 

C  encountered,  there  are  two  responses.  Get  the  first  and  then 

C  get  the  second.  Otherwise,  get  the  first  response  only  and 

C  return  to  the  calling  program. 

C 

IF  (IINITAR(l)  .NE.  KLTRI)  GO  TO  1004 
DO  1008  ISUB1  =  9,  1ID1M1 

IF  (IINITARdSUBl)  .  EQ.  KSJACE)  GO  TO  1014 
IF  (IINITARdSUBl)  .EQ.  KOKMA)  GO  TO  1010 
IlSTRSPdSUBl  -  8)  =  UNIT  AR(  ISUB1 ) 

I1STSZ  =  ISUE1  -  8 

1008  CONTINUE 
C 

C  **  Begin  the  search  for  the  second  response,  if  any.  Return  ** 
C  to  the  calling  program  v/hen  completed. 

C 

1010  IP1SUB1  =  ISUB1  +  1 

DO  1012  I SUB 2  =  IP1SUB1 ,  KDIM1 

IF  ( 1INITAR(  ISUB2)  .EQ.  KSl’ACE  .OR.  IINITAR(ISUB2) 

+  .EQ.  KOMMA)  GO  TO  1014 

I2NDRSP( ISUB2  -  ISUBl)  =  IINITAR(ISUB2) 

12NDSZ  =  1SUB2  -  ISUBl 

1012  CONTINUE 
C 

c 

C  **  Before  returning  to  the  calling  program,  the  pointer  to  the  ** 
C  action  file  must  be  reset  to  the  beginning  of  the  file.  FSEEK 

C  resets  the  pointer  to  the  beginning. 

C 

1014  CALL  FSEEK  ( I ECU AN, 0) 

C 

RETURN 

END 

C 

C - 

c - 

C 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

C  +  + 

C  +  END  GETRSPS.FR  + 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

c 

c - 

C - 
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+  +  +  +  +  +  +  +  +  +  •4  -4  +  +  +  +  +  +  +  +  +  +  +  +  + 


+  CNVRT. SR 

+  ****  CRKATED  15  JULY  1980; 

+ 

+  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


+ 

+ 

RKV  04  ****  + 

+ 

+  +  +  +  +  +  +  + 


•k  ic  x  **  ic  k  Vf  if  if 

Program  CNVRT. SR  is  called  from  MONITOR. FR  and  returns  to 
MONITOR.  It  is  called  after  GETRSPS.FR  and  serves  to  convert 
the  FORTRAN  array  storage  to  assembly  language  storage.  Foe  example, 
the  character  "A"  is  stored  in  FORTRAN  array  IRSP1  as  < 1 0 1 > <4C > , 
whereas  the  same  character  is  stored  in  assembly  language  as 
<0><101>.  Thus,  this  program  simply  converts  between  the  two. 

The  call  to  CNVRT  is  as  follows: 

CALL  CNVRT  ( IRSP1 , 1RSP2 , II SSZ , I2SSZ) 

IRSPl  and  IRSP2  are  one-dimensional  FORTRAN  arrays  that  arc  passed 
from  MONITOR  to  CNVRT.  They  contain  the  responses  as  found  by 
the  program  GLTRSPS.  I1SSZ  and  12SSZ  are  the  size  of  the  response 
arrays,  and  are  parameters  that  are  passed  from  CNVRT  to  MONITOR. 

Upon  completion  of  CNVRT,  the  assembly  language  responses  and  their 
sizes  are  stored  in  BUF1  ,  BUF2,  .FBI,  and  .FB2,  respectively. 
Subsequent  programs  then  use  these  locations  for  comparison 
purposes,  when  checking  for  appropriate  responses. 

■k'k'ieick't.’k'k’k'k 


•TITL  CNVRT  ;Program  name  -  Convert 

.ENT  CNVRT  ;Enables  outside  entry  into 

.ENT  .BUF1,  .BUF2,  .FBI,  .FB2  ;this  program  and  these  locations 

.TXTM  I  ;Packs  ASCII  strings  left  to  right 

•EXTD  .FSUB,  .FREDI  ;FORTRAN  runtime  library  routines  must 

;be  decleared  external  displacements 

.EXTU  ;Undefined  variables  are  treated  as 

;External  Displacement  variables 

.EXTN  .1  ;Provides  some  FORTRAN  initialization 


» 
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> 

.  ZREL 

;Zero 

rel  o 

eatable  space  starts 

.FBI  : 

0 

;  Store 

for 

the  size  of  first  re: 

*ponse 

.  FB2 : 

0 

;  Same 

for 

second  response 

.  BIJF1  : 

BUFI 

; Buf  f  e 

rc  t 

hat  contain  response's 

may  be 

. BUF2 : 

BUK2 

jaddre 

ssed 

indirectly  via  these 

locat i on 

.NR  EL 


;Normal  relocatable  space  starts 


FS. 


ESTABLISH  THE  ARRAYS  PASSED  IN  AS  DUMMY  ARGUMENTS 


CNVRT :  JSR  0  .FARL 


J SR  Q  .FRED 
ARY2IN 
(3  STORA+1 
STORA+4 


jRedimension  an  array,  passed  as  dummy 
;argument.  This  is  array  specifier 
;This  is  array  size  -  dummy  argument 
;This  is  three  word  sta<.’’  specifier 


JSR  (?  .FRED 

ARY1IN  ;Same  for  the  other  array 

(a  STORA+0 

STORA+7 


STORE  SIZE  OF  RESPONSES 


LDA 

1  , 

PTMP+3,  3 

;Louu  size  of  second  array 

from 

STA 

1, 

.  FB2 

JFORTRAN  stack  -  store  in 

.  FB2 

LDA 

1, 

OTMP+2,  3 

;Same  for  first  array,  but 

STA 

1, 

.FBI 

;store  in  .FBI 
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SELECT  EACH  ELEMENT  OF  THE  FIRST  ARRAY 


J 

LDA  0,  MINI 2 SUB 

;Load  subscript  one 

STA  0,  TMP+12, 

3 

;Store  on  stack 

JMP  STRT1 

;Start  iterations 

IKC1S: 

LDA  0,  TMP+12, 

3 

;On  repeated  passes,  get  the 

INC  0,  0 

;last  subscript  and  increment  it 

STA  0,  TMP+12, 

3 

;Store  new  subscript 

STRT1 : 

LDA  1,  0TMP+2 , 

3 

;Load  maximum  subscript 

SUEZ  0,  1,  SNC 

; If  maximum  exceeded, 

JMP  NXTRSF 

;start  same  type  iteration  on  next  array 

JSR  <2  .FSUB 

;Otherwise,  get  the  array  element 

3 

;Number  of  arguments  for  library  call 

STORA+7 

;St3ck  specifier  for  first  array 

STORP+1 

;Temporary  location  for  FSUB  result 

STORA+12 

;FORTRAN  address  of  subscript 

;  CONVERT  FROM  FORTRAN  TO  ASSEMBLY  LANGUAGE  STORAGE 


LDA  0,  @TMPP+ 1 ,  3 

LDA  2,  MSKSAP 

ANDS  2,  0 

STA  0,  (jBUFIPTR 

LDA  1,  BUF1PTR 

INC  1,  1 

STA  1,  BUF1PTR 


;Load  selected  array  element 

;Delete  second  byte,  strip  parity  from 

;first  byte,  and  swap  bytes 

;Store  result  in  BUF1 

;Load  pointer  to  BUFFI 

; Increment  and  store  the  new 

;pointer 


JMP  INC1S 


;Continue  the  next  iteration 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERROR:  . SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  ERROR 


1 3  A 


DEFINE  INITIAL  SUBSCRIPT  SIZE  FOR  BOTH  ARRAYS 


MINI 2SUB : 1 

:  REPEAT  THE  ABOVE  PROCEDURE  FOR  THE  SECOND  ARRAY 


NXTRSP:  EDA  0,  MINI 2 SUB 
STA  0,  TMP+12 ,  3 
JMP  STRT2 

INC2S :  LDA  0,  TMP+12,  3 
INC  0,  0 

STA  0,  TMP+12,  3 

STRT2  :  LDA  1  ,  <?TMP+3  ,  3 
SUBZ  0,  1,  SNC 

JMP  RETN  ;Return  to  calling  program 

JSR  @  .FSUB 
3 

STORA+4 

STORP+2 

STORA+12 

LDA  0,  0TMPP+2,  3 
LDA  2,  MSKSAP 
ANDS  2,  0 

STA  0,  0BUF2PTR  ; Store  result  in  BUF2 

LDA  1,  BUF2PTR 

INC  1,  1 

STA  1,  BUF2PTR 

JMP  INC2S 


i 

I 

l 


I 

I 
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define  pointers,  vakai bees,  and  bohers 


KSKSAP :  077 AGO 


Bl'l-’l  PTR :  BUFl 
BUF2PTK :  BUF2 


jMatik  for  Ft  r  i  pping  parity,  do]  (tin,; 
; second  byte 

•.Pointer  to  BIT  I 
; Point or  to  BUF2 


BUFl :  .  BEK  40.  ;Dcfine  buffer  sizes 

BUF2 :  . BEK  40. 


RETN :  J SR  Q  .FRET 

SPECIFY  ']1!K  ARRAYS 


AP.Y21N: 

3 

;  Tli  i  f 

is 

-  2*( number  o f  subsci  ipt.s)  +  l 

401 

;  Th  i  s 

i  s 

-  400"  1  +  1,  1  on  t  b:-  i  and  type- 

KIN]  2 SUP, 

;  Th  is 

i  s 

lover  subscript  size 

0STORA+  3 

;  Th  .i  s 

is 

higher  subscript  size 

ARY1IN: 

3 

;  Th  i  s 

is 

the  same  for  first  array 

401 

MIN] 2 SOB 

0STURA+2 

DEFINE  STACK  PARAHFTFF.S 


FS .=17 
TMP=-167 
STORA=200  HIP 
TMPP=TMP+ 1 2 

STORP=STOKA+ 1 2 


;Frame  size*  for  all  stack  variables 
;Middle  of  the  user's  stack 

;First  word  available  for  temporary 
; storage 


.END  CNVRT 


+  +  +  +  +  +  +  +  +  •+  +  +  +  +  ■»  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  CNVRT. SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c- 

c- 

c 


+  +  +  +  +  +  +  +  +  +  H  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 
+  WRIT SYSTM.FR  + 
+  ****  CREATED  8  AUGUST  1980;  REV  00  ****+ 
+  + 
+  +  +  +  -t  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


'i*  A*  W  X  X  a'V'A' 


c 

C  Program  URITSYSTM. FR  is  called  by  MONITOR. FR  and  returns  to 

C  MONITOR,  whenever  a  command  sequence  from  an  action  file  is 

C  ready  to  be  sent  to  the  "system."  URITSYSTM  provides  a 

C  transition  to  and  from  an  assembly  language  subroutine  that 

C  actually  transmits  data  to  the  "system."  The  call  to 

C  URITSYSTM  is  as  follows. 

C 

C  CALL  URITSYSTM  ( IACTFILE , NKTMSTIKDX , $602 ) 

C 

C  IACTFILE  is  one  line  from  the  action  file  that  is  to  be  sent 

C  to  the  "system."  NKTMSTINPX  is  the  size  of  the  one-dimensional 

C  array  IACTFILE,  and  $602  is  the  return  line  number  in  MONITOR 

C  that  will  next  be  executed  upon  return  from  URITSYSTM.  All 

C  parameters  art!  passed  to  WRJTS1SIM  from  MONITOR. 

C 

0  'k'k’ic’irk't.'ic’k'ic’ic 

c 

c - 
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**  V.’nnr.YST?*  receives  an  input  array,  the  dimension  of  that.  ** 
array,  and  an  assigned  downy  return  variable. 

SUR'HU’TINE  l.'R  I  TSYST11  ( 1)!]  ARRAY ,  1 1  D I  MAR ,  1 1 DUMRTH  ) 

DIMERS  1  OR  11.1  ARRAY  ( 1 1  Dl.’tAR) 

WP.SYS  actually  transmits  the  contents  of  INI  ARRAY  (of  size  ** 
INIDIMAR)  to  the  "system." 

CALI,  WRSYS  ( I N 1  ARRAY  ,  I1DIMAR) 

**  Return  to  the  statement  number  passed  in  I1DUMRTN  ** 

RETURN  IIDUjIRTN 
END 


+  +  +  +  +  +  +  +  +  +  *f  +  +  -f  +  +  +  +  +  +  +  +  +  +  +  -f  + 


END  WRITSYSTn.FR 


+  +  +  +  +  +  +  +  •»+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ■(  +  + 


138 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  + 


4  4 

4  WRSYS.SR  4 

+  ****  CREATED  15  JULY  1980;  REV  03  ****  4 

4  4 


4444  44444444444444444444444 


Program  WRSYS.SR  is  called  from  WRITSYSTI'.FR  and  returns  to 
WRITSYSTII.  Its  sole  function  is  to  transmit  data  to  the  "system. 
The  data  is  always  a  command  of  the  action  file.  The  call  to 
WRSYS  is  as  follows: 

CATA,  WRSYS  ( INI ARRAY ,  I1DIMAR) 

INI ARRAY  is  one  line  from  the  action  file  that  is  to  be  sent  to 
the  "system."  II  DINAR  is  the  size  of  the  onc-dimentional  array 
INI ARRAY.  Both  these  parameters  art  passed  from  WRITSYSTM  to 
WRSYS. 


Jckick'k  *A  kk 


.  TITL 

WRSYS 

; Program  name  -  Write  to  System 

.ENT  WRSYS 

; Enables  outside  entry  into  this 
•.program 

.  TXTM 

1 

;Packs  ASCII  strings  lift  to  right 

.EXT  I) 

. FSUB ,  .FREDI,  .LD1 

; FORTRAN  runtime  library  routines  must 
;be  declared  external  displacements 

.  EXTU 

;Undefined  variables  are  treated  as 
;External  Displacement  variables 

.  EXTH 

.1,  .ASUSP 

;.I  provides  some  FORTRAN  initialization 
;. ASUSP  is  a  task  call  for  suspension 
;and  must  be  declared  external  normal 

.NREL  ;Normal  relocatable  space  starts 

FS. 


139 


SKPBZ  TT01 
JMP  .-1 
DOAS  0,  TTOl 
JMP  INCSUB 

DEFINE  VARIABLES 


OR:  15 

LOWSUB:  11 

MSKIT :  077400 

TSKPRI:  0 
MINSUB:  ] 


•,If  the  output  line  (channel  device  $TT0 
;is  busy,  try  again 
;Otherwise,  output  the  character 
;Continue  the  next  iteration 


;Carriage  return  is  octal  15 
;9  decimal  -  subscript  that  starts 
jaction  file  text 

;Mask  for  stripping  parity,  deleting 
;second  byte 

;MONITOR's  task  priority 

;The  lower  subscript  starts  at  one 
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SPKC1FY  TtIK  ARRAY 


:  3 

;  Th  i  s 

is  -  2*( number  of  subscript 

s )  +  1 

40 1 

;  Th  i  s 

is  -  400*1  +  1,  len;;tn  =  l  and 

type 

MINSUB 

;  Th  i  s 

is  lower  subscript  size 

0STOR/.+  ] 

;This 

is  higher  subscript  size 

OUTPUT  CARRIAGE 

RETURN,  SUSPEND  MONITOR, 

AND  RETURN 

RET:  LDA  0,  CR 

SKFBZ  TIOl 
JMP  .-1 
BOAS  0,  TTOl 

LDA  0,  TSKPUI 
.ASUSP 


;I.oad  carriage  return 
;Output  it  when  $TT01  not  busy 


;Load  MONITOR  task  priority 
; Suspend  MONITOR  -  task  SYSI.K  will 
; ready  MONITOR 


JSR  @  .FRET 

DEFTKE  STACK  PARAMETERS 


FS.=7 
TKP=-167 
ST ORA-  200+TMP 
TMPP=TMP+5 


STORP-STORA+  5 
•END  WRSYS 


;Frame  size  for  all  stack  variables 
;Middle  of  the  user's  stack 

;First  word  available  for  temporary 
; storage 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  WRSYS . SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


1 41 


C - - - - — 

c 

C  +  +  +  +  +  +  +  +  +  +  -T  +  +  -I  +  +  +  +  +  +  +  +  +  +  +  +  + 


c  +  + 

C  +  WR1TL0CA1. .  KR  + 

C  +  ****  CREATED  8  AUGUST  1980;  REV  00  ****+ 

C  +  + 


C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ■»•)•  +  + 

c 


c 

0  k  k  k  k  k  k  k  k  k  k 

c 

C  Program  WRTTLOCAL .  FR  is  called  by  MONITOR. FR  and  returns  to 

C  MONITOR,  whenever  n  command  sequence  from  an  action  file  is 

C  ready  to  be  sent  to  the  "local"  terminal.  WR 11 LOCAL  simply 

C  writes  a  string  contained  in  array  IN2ALRAY  to  the  "local" 

C  terminal.  The  call  to  WRIT LOCAL  is  as  follows: 

C 

C  CALL  WRITLOCAL  ( IACTFILE, MDIMl , $602) 

C 

C  IACTFILE  is  one  line  from  the  action  file  that  is  to  bo  sent 

C  to  the  "local"  terminal.  MDIMl  is  the  size  of  the  one-dinent icmal 

C  array  IACTFILE,  and  $602  is  the  return  line  number  in  MONITOR 

C  that  will  be  next  executed  upon  return  from  WRITLOCAL.  All 

C  parameters  are  passed  from  MClllTOll  to  Will'll. GCAL. 

C. 

C  *  *  k  k  vc 'A  'irk  k  k 

c 

c - 

c - 
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C  **  WRITI.OCAL  receives  an  input  array,  the  dimension  of  that 
C  array, and  an  assigned  dummy  return  variable. 

C 

SUBROUTINE  WRITLOCAL  ( I N2 ARRAY , I2DIMAR , I2DUMRTK) 

DI MENS 1 ON  IN2ARRAY( I2DIMAR) 

C 

C  **  The  contents  of  the  action  file  line  are  written  to  channe 
C  10,  the  "local"  terminal  device  ($TT0). 

C 

WRITE  (10,  2001)  (IN2ARRAY(J1),  Jl  =  3,  I2DIMAR) 

2001  FORMAT  (80A1) 

C 

C  **  Return  to  the  statement  number  passed  in  I2DUMRTK. 

C 

RETURN  I2DUMRTN 
END 
C 

C - 

C - 

c 

c  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
c  +  + 

C  +  END  WRITLOCAL.FR  + 

c  +  + 

c  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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ooooonoooooo  noo  ono  oonnonooooooooo 


4444444444444  4  4444444444  4  44 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c- 

c- 

c 

c 

c 

c 

c 

c 

c 

c 

c 


+ 

+  RF,ADI,WR1TS.FR 

4  ****  CREATED  8  AUGUST  1980;  REV  00 

4 


+ 

4 

ic'k-k  r.  + 

4 


4  4  4-)  4444  4-444444444444444444 


4.'  vV  k  'k  'X  >;  -V  -A  v: 

Program  READLUR1TS . FR  is  called  by  MONITOR. FR  and  returns  to 
MONITOR,  whenever  a  command  sequence  from  an  action  file 
indicates  that  something  is  to  be  read  from  the  "local"  terminal 
and  a  carraiage  return  is  to  be  sent  to  the  "system." 

READLWRITS  provides  a  transition  to  and  from  an  assembly 
language  subroutine  that  actually  reads  data  from  the  "local" 
terminal  and  writes  a  carriage  return  to  the  "system." 

The  call  to  READLWRITS  is  as  follows: 


CALL  READLWRITS  ($602) 


The  $602  is  the  return  line  number  in  MONITOR  that  will  next 
be  executed  upon  return  from  READLWRITS. 

*  *  *  *  *  *  *  *  'k  * 


**  READLWRITS  receives  an  assigned  dummy  return  variable. 

SUBROUTINE  READLWRITS  (I3DUMRTN) 

**  RDAWR  actually  implements  the  read  and  write  functions. 
CALL  RDAWR 

**  Return  to  the  statement  number  passed  in  I3DUMRTN. 

RETURN  I3DUMRTN 
END 


444444444444444444444444444 
4  4 


4 


END  READLWRITS . FR 


4 


4 


4 


4444444444444444444444444  4  4 
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RDAWR.SR 

icicic'k 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  1 

+ 
+ 

CREATED  3  JULY  1980;  REV  03  ****  + 

+  + 
+  +  ♦  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


********** 

Program  RDAWR.SR  is  called  from  READLWRITS . FR  and  returns  to 
READLWRITS.  Its  solo  purpose  is  to  await  any  keyboard  input 
and  then  transmit  a  carriage  return  to  the  "system."  This 
routine  is  only  called  during  LOGON  processing.  There  are  no 
arguments  or  parameters  that  are  passea  via  RDAWR. 

'k£~k‘k'k'k  'k  *A'  'k  * 


i 


i  in  no 


Road  And  Write- 


.Tin,  RDANR 


;  Program 


.ENT  RDANR 


;  F.nabl  os  outside  entry  into  this 
; program 


. TXTM  1 
.  EXTU 

.  EXTN  .1,  .  ASllSP 


;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
; as  External  Displacement  variables 

;.I  provides  some  FORTRAN  initialization 
;.ASUSP  is  a  task  call  for  suspension 
;and  must  be  declared  external  normal 


.ZREL 


;Zero  relocatable  space  starts 


.ER:  ERROR 


;Acccss  to  ERROR  may  be  gained  via 
{indirect  addressing  to  this  location 


. NREL  ;  Nonna  1  relocatable  space  starts 

FS. 

WAIT  FOR  KEYBOARD  INPUT 


RDAWR : 

JSR  @  .FARE 

RERD: 

. SYSTM 

.  GCHAR 

;Get  input  character  from  keyboard 

JMP  Q  .ER 

SK ND  CAKKIAOK  RETURN  TO  5TT01 


l.DA  0.  CK 

jl.oad  a  carriage  return 

.SYSTM 

. PCHAR 

;Oulput  carriage;  return  to  $TT'J 

JMP  O'  .HI 

SKTRZ  TTO) 

;Is  $TT01  busy? 

JMP  .-1 

;Yes  -  try  again 

DOAS  0,  TTUl 

; No  -  output  carriage  return  to  $TTOl 

1 

> 

SUSPEND  TUP  TASK  MONITOR 

TO  ALLOW  SYS  IN  TO  EXECUTE 

LDA  0,  TSKPR1 

;Load  MONITOR'S  task  priority  (0) 

.ASUSP 

^Suspend  MONITOR  until  readied  in 

;task  SYS1N 

JMP  RTN 

;Jump  to  rcLurn  location  when  complete 

J 

t 

DEFINE  VAR1AP.LFS 

TSKPR1  :  0 

;MONITOR's  task  priority  is  rero 

CR: 

15 

;A  carriage  return  is  octal  15 

> 

ROUTINE  TO  RETURN  TO  THE 

CL I  ABNORMALLY 

ERROR :  .  SYSTM 

•  ERTN  ;Abnormal  return  -  error 

JMP  0  .ER 


> 

RTN:  JSR  0  . FRET 


FS.=0 

TMP=-167 

.END  RDAWR 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 

+  END  RDAWR. SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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ooooooooo 


c 


c— 

— 

— 

— 

c 

c 

+ 

+  4  4  4  + 

4  4  4  4  4 

4 

4  4  4  4 

4  4  4 

4  4 

4  4 

4  4  4 

c 

4 

4 

c 

4 

SENDFILE. 

.FK 

4 

c 

+ 

**w* 

CREATED 

8 

AUGUST 

1980; 

REV 

00 

***** 

c 

4 

+ 

c 

4  4 

4  4  4  4  4 

4  4  4  4  4 

4 

4  4  4  4 

4  4  4 

4  4 

4  4 

4  4  4 

c 

c — 

c - 

c 

p  ********** 

c 

C  Program  SENDFILE. FR  is  called  by  MONITOPv.FR  and  returns  to 

C  MONITOR,  whenever  a  command  sequence  from  an  action  file 

C  requires  a  "local"  disk  file  to  be  sent  to  the  "system. " 

C  SENDFILE  uses  the  RDOS  file  CLI.CM  to  "send"  action  file  commands 

C  to  the  "local"  system.  Thus,  the  action  file  conminand  is  inserted 

C  into  CLI.Cil  and  then  a  program  swap  takes  place  to  execute  that 

C  command.  When  swapping  takes  place,  functions  within  tasks  are 

disabled  (such  as  . IDEF).  Therefore,  the  task  SYS1N  is  inactivated 
(killed)  and  reactivated  before  and  after  the  swap  -  program 
EXCLI.SR.  Finally,  program  GETFILE.SR  actually  transmits  the 
data  retrieved  from  the  "local"  disk  and  sends  it  to  the 
"system."  The  call  to  SENDFILE  is  as  follows: 

CALL  SENDFILE  ( IACTFILE, MDIMl ,$602) 

IACTFILE  is  one  line  from  the  action  file  that  is  to  be 
C  acted  upon  by  the  "local"  system.  MDIM1  is  the  size  of  the 

C  one-dimensional  array  IACTFILE,  and  $602  is  the  return  line 

C  number  in  MONITOR  that  will  next  be  executed  upon  return  from 

C  SENDFILE.  All  parameters  are  passed  to  SENDFILE  from  MONITOR. 

C 

c  ********** 

C 

c - 

C - 


I 
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c 

C  **  SENDl’ILE  receives  an  input  array,  Llio  dimension  of  that  ** 

C  array,  and  an  assigned  dummy  return  variable. 

C 

SUBROUTINE  SFNDFILK  (1K4 ARRAY , 1 4 1)1 MAR , I4DUMRTN ) 

C  **  SYSIN.SR  is  the  task  program  that,  monitors  "system"  input  ** 

C  and  was  activated  by  MONITOR.  As  it  is  to  be  killed  and  then 

C  reactivated,  DG  FORTRAN  required  that  it  be  externally  defined. 

C 

EXTERNAL  SYS IN 

DIMENSION  IK4ARRAY( I4DIMAR) 

C 

C  **  This  call  creates  file  CLI.CM.  If  it  already  exists,  an  ** 

C  error  of  12  is  returned  in  KERRI.  If  the  call  is  okay,  an 

C  error  of  1  is  returned.  Any  other  error  is  printed  out  for 

C  reference.  This  insures  that  CLI.CM  is  available. 

C 

CALL  CFILW  ("CLI.CM", 2, KERRI) 

IF  (KERRI  .NR.  1  .AND.  KERRI  .NE.  12)  TYPE  "KERRI  IS  ", KERRI 
C 

C  **  This  call  opens  file  CLI.CM  or>  channel  25.  State  the  error  ** 

C  condition  if  not  opened  properly. 

C 

CALL  OPEN  ( 25 , "CLI . CM" , 2 ,K ERR2 , 32 ) 

IF  (KERR2  .NE.  1)  TYPE  "KERR2  IS  ",  KERR2 
C 

C  **  Insert  command  sequence  from  action  file  into  CLI.CM.  ** 

C 

WRITE  (25,4001)  (IK4ARRAY(K1),  K1  =  3,  I4DIMAR) 

4001  FORMAT  (111  ,  80A1) 

**  Close  CLI.CM  so  it  can  be  deleted  in  EXCL1.SR,  after  it  is  ** 

C  no  longer  needed. 

C 

CALL  CLOSE  (25,KF,RR3) 

IF  (KERR3  .NE.  1)  TYPE  "KERR3  IS  ",  KERR3 
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a  o  o 


c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 


c 

c 

c 

c 


c 

c 

c 

c 

c 


**  Before  executing  the  swap  ( EXCLI ) ,  inactivate  SYS  IK.  ** 

SYSIN  is  the  only  task  with  priority  one  (1). 

CALL  AKILL  (1) 

**  EXCLJ  swaps  to  level  two  (2)  to  execute  the  instruction 

just  inserted  into  CLI.CH.  Level  two  (2)  is  the  RDOS  CLI . 

Upon  completion  of  the  swapped  prograta,  control  returns  to  the 
next  instruction  in  this  program. 

CALL  EXCLI 

**  Reactivate  SYS I II  just  as  it  was  before  the  swap.  ** 

CALL  ITASK  ( SYS  IN , 10 , 1 ,KERR4 , 1 ) 

IF  (KERR A  . LE .  1)  TYPE  "KF.RR4  IS  ",  KERRA 

**  GETF1LE.SR  transmits  the  data  on  file  QQVV  to  the  "system."  ** 

CALL  GETFJI.E 

**  Return  to  the  statement  number  passed  in  IADUMRTN.  ** 

RETURN  IADUMRTN 
END 


+  +  +  +  +  +  +  + 

+ 

+ 

+ 

+  +  +  +  +  +  +  + 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

+ 

END  SENDFILE.FR  + 

+ 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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+  +  +  +  +  +  -f4  +  +  +  +  4  +  +  +  +  +  +  +  +  +  -t  4  4  4  4 


4 

4 

4 

+ 

+ 


4 


EXCL1.SR  + 

****  CREATED  22  JULY  1980;  REV  01  ****  4 

4 

+  +  +  +  +  +  +  +  +  +  +  -»  4444444444444 


k  vr  v»  v»  '/v  a  "x  v>*  v*  a 

Program  EXCI.l. SR  is  called  from  SKNDFJLK.FR  and  KECF.VF I.LE.FU, 
and  returns  to  SLNDP1LE  and/or  RECEVF1I.E,  whichever  program 
called  KXCLI  last.  The  purpose  of  EXCI.l  is  to  execute  the 
RDOS  Chi  on  level  two  (2)  by  swappir.  the  CLI  in  and  swapping  out 
E.XCL1.  A  command  Iron  the  action  file  has  been  inserted  inLo 
CLI. CM  by  either  SEiJDFJ  LK  or  RECEVF1LE;  this  swap  executes 
these  commands.  EXCI.l  also  appends  a  POP  command  in  the  CLI. CM 
file,  in  order  to  return  to  level  one  (1)  -  the  program  EXCL1  - 
upon  completion  of  the  command  sequence  inserted  into  CLI. CM. 
There  are  no  arguments  or  parameters  that  are  passed  via  EXCI.l. 

k  k  k  k  k  k  k  k  k  k 


.TITL  EXCI.l 
.ENT  EXCI.l 


; Program  name  -  Execute  the  CLI 

jEnables  outside  entry  into  this 
;  program 


.  TXTM  1 
.  EXTU 

. EXTN  .1 


;Packs  ASCII  strings  left  to  right 

jUndefined  variables  are  treated  as 
jExternal  Displacement  variables 

jProvides  some  FORTRAN  initialization 


•NREL  ;Normal  relocatable  space  starts 

FS. 
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ADI)  THE  POP  COMMAND  TO  FILE  CLI.CM 


EXCLI:  J SR  C  .FARE 


SUB  1  ,  1 
LDA  0,  CL I CM 
. SYSTM 
.APPEND  23 
JMP  ER 

LDA  0,  CMAND 
LDA  1 ,  B COUNT 

.SYSTM 
.  V.'RS  23 
JMP  ER 
.SYSTM 
.CLOSE  23 
JMP  ER 


;Load  the  default  mask 

;Load  the  byte-pointer  to  file  CLI.CM 

;Open  CLI.CM  for  appending  on  channel  23 

;Load  bytepoint.er  to  additional  command 
;Load  number  of  bytes  to  be  written 

;Write  the  added  command  to  CLI.CM 

;Now  close  file  CLI.CM 


CALT,  SWAP  TO  EXECUTE  THE  CL1 


LDA  0,  CLISV 
SUB  1,  1 
SUBZL  2,  2 
.SYSTM 
.EXEC 
JMP  ER 
JMP  RT 


;Load  bytepcinter  to  file  CLI.SV 
;Load  zero  -  indicates  swap 
;Send  no  message  to  swap  program 

;Swap  to  CLI  on  level  two  (2) 

;Jump  to  return  location  when  complete 


ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ER:  .SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  ER 


DEFINE  BYTEPOINTERS,  ETC. 


> 

CLISV: 

.  +  1*2 

.TXT  "CLI.SV" 

;Bytepointer 

to 

file  CLI.SV 

CLICK : 

.  +  1*2 

.TXT  "CLI.CM" 

;Bytepointer 

to 

file  CLI.CM 

CMAND : 

.  +  1*2 

.TXT  ";P0P<15>" 

;Bytepointer 

to 

POP  command 

BCOUNT: 

(  BCOUNT-CMAND)*2 

;Number  of  bytes 

in  POP  command 
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ehlut.  file  cu.cm  immork  i;k'hii:ni:;c:  to  calling  prockam 

;I.oad  byl.opoint.rr  to  file  CLI.CM 
; Do  lot  c  file  CLI.CM 


JSR  P  .  FRET 

FS  .=0 
TMP=-167 

.END  EXCLI 


LDA  0,  CLICM 
. SYSTM 
.DELHI 
JMP  HR 


^  +  +  ^■  +  +  +  ^•  +  +  ^  +  +  +  +  +  +  +  +  + 
t 

t-  END  EXCLI.  SR 

► 

t  +  +  +  +  +  +  +  +  +  +  +  +  •!•  +  +  <  +  +  H- 


h  +  *f  T  +  +  + 

+ 
+ 
+ 

+  +  +  +  +  +  + 


1  53 


•S-  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  1-  +  +  H  +  +  +  +  +  +  + 


+  + 

+  GETFTI.fi .  SR  + 

+  ****  CREATED  26  JULY  1980;  REV  02  ****  + 

+  + 


+  +  +  +  +  +  +  +  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


V'.i  <rr  a  "in  'r>  ‘a 

Program  GKTF1EE.SR  is  called  frou  SENDF1LE.FR  and  returns  to 
SENBF1LE.  It  is  called  after  1IXCLI  has  placc-d  a  disk  file  of 
the  "local"  system  into  file  QQVV.  It  gets  this  file  and 
outputs  it  to  the  "system"  character  by  character.  It  calls 
upon  a  system  call  to  determine  the  User  File  Discription 
status,  which  provides  the  size  of  the  file.  There  are  no 
arguments  or  parameters  that  are  passed  via  GETl’ILE. 

V  Vs  Vf  a  V«  X  «{  V.'  Vi  Vf 


. TITL  GFTFILK 
•ENT  CHIP ILF 

. TXTH  1 
.  EXTU 

•EXTM  .1 


; Program  name  -  Get  File 

;Enables  outside  entry  into  this 
; program 

;Packs  ASCII  strings  left  to  right 

;Undefined  varaiblcs  are  treated  as 
;External  Displacement  variables 

; Provides  some  FORTRAN  initialization 


•  NREL  ;Normal  relocatable  space  starts 

FS. 
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OIT.;;  AND  FIND  S'jATUS  ok  1-ILK  QQVV 


GETF  J  LL : JSR  G  .FALL 

LDA  0,  KA.’TOFFL 
SUB  1,  1 
.  SYSTM 
. OPEN  26 
JMP  Eii 

L!)A  1 ,  STRLOC 
.  SYSTM 
■  STAT 
JMP  ER 

JMP  CALCS 7. 

;  READ  QQVV  BY  PORTIONS  AND  SEND  OUT 


AGIJKD:  I. DA  3,  SZOFFL 
LDA  I,  KYTSZ 
SUEZ#  1,3,  SNC 

JMP  LSTRD 

STA  1 ,  WRSRZ 
LDA  0,  PTRCNTS 
.SYSTM 
. UDS  26 
JMP  ER 

JSR  SEKDIT 

LDA  1  ,  IYYTSZ 
LDA  3,  SZOFFL 
SUB  1  ,  3 
STA  3,  SZOKFL 
JMP  AGKRD 

LSTRD:  LDA  0,  PTRCMTS 
LDA  1 ,  SZOfPL 
STA  1,  WRSSZ 
•SYSTM 
. RDS  26 
JMP  ER 

JSR  SEKDIT 

LDA  0,  CR 

SKPBZ  TTOI 
JMP  .-1 
DOAS  0,  TTOI 


;Load  bytepointer  to  file  QQVV 
;  Load  default  j.iask 

;Open  file  QQVV  on  channel  26 

;Load  pointer  to  beginning  of  LTD  store 
; Get  t  he  II I’D  sLatus  of  QQVV 

;Now  calculate  the  size  of  QQVV 


;Load  the  size  of  file  QQVV 
;I.oad  the  size  of  the  GETS  store 
; I s  current  size  of  file  greater 
;than  size  of  CUTS? 

;Ko  -  read  QQVV  for  the  last  Line 

;Yes  -  read  at  least  ten  tir.es 
;Load  bytepointer  t c>  buffer  GETS 

;Read  a  portion  of  QQVV  into  CRTS 

;Send  this  portion  out 

; Load  the  size  of  the  GETS  buffer 
;and  the  current  size  of  QQVV  not  read 
;Find  the  difference  between  the 
; two  and  store  in  SZOKFL 
;Returu  to  read  the  next  portion 

;Load  the  bytepointer  to  GETS 
;Load  the  current  size  of  QQVV 
; Store  this  size 

;Read  in  the  last  portion  of  QQVV 

;Send  this  portion  also 

;Load  a  carriage  return 

; 1 £  the  output  line  is  not  busy, 

;send  a  carriage  return  as  the  last 
; character 


15b 


ONCE  COMPLETE,  CLOSE  AND  DELETE  QQVV 


TRYCLOS :LDA  0,  NAMOFFL 

. SYSTM 
.CLOSE  26 
JMP  CHKERR 

.SYSTM 
.DELET 
JMP  ER 

JMP  RETERN 

CHKERR:  LDA  1,  . ERFIU 
SUB  2,  1,  SNR 
JMP  TRYCLOS 
JMP  ER 

;  ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ER:  .SYSTM 

-ERTN  ;Abnormal  return  -  error 

JMP  ER 

DEFINE  VARIABLES,  BYTEPOINTERS ,  AND  BUFFERS 


.ERFIU:  ERFIU  ;ERFIU  =  60,  file  in  use 

NAMOFFL +1*2  ;Bytepointer  to  file  QQW 

.TXT  "DPOF: DIALOG: QQVV" 

STRLOC:  UFDSTR 
UFDSTR:  . BLK  22 

SZOFFL :  0 
BYTSZ :  122 

PTRINIT : CNTS 
TEXTPTR : CNTS 
PTRCNTS : CNTS*2 
WRSSZ:  0 


;Pointer  to  UFD  store 
; 1 8  decimal  UFD  word  store 

;Store  for  current  size  of  file 
; 82  decimal  bytes  -  CNTS  buffer 
;Pointer  to  the  beginning  of  CNTS 
•jPomter  to  text  entries  for  CNTS 
;Bytepointer  to  CNTS  buffer 
;Number  of  bytes  to  be  written 


;Load  bytepointer  to  QQVV 
•.Close  file  QQW 

;Check  to  see  if  there  is  an  expected 
; error 

;  If  not,  delete  QQVV 

;Then  return  to  the  calling  program 

;Is  QQVV  still  in  use? 

;Compare  to  error  code  ERFIU 

;Yes  -  return  to  try  for  closing  again 

.Otherwise,  state  the  unexpected  error 
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CAi.ei'i.ATK  niK  size  or  qqvv 


CALCS Z :  1,DA  3,  ZERO 

LDA  1,  UFDSTR+IO 
SUBi?  3 ,  1  ,  SNR 
JMP  ADONCE 


;Load  zero  (0) 

;Load  the  number  of  the  last 
jblock  in  QQVV.  Is  it  zero? 

;Yos  -  just  calculate  once  the  size 


STA  1 ,  CUTER 
LDA  0,  ZERO 
LDA  2,  OKEBLK 


;No  -  load  the  number  of  blocks  in 
;counter  and  load  zero 
;Load  the  size  of  one  block 


KELT:  ADD  2,  0 

DSZ  CUTER 
JKP  MULT 


;Multiply  the  number  of  blocks 
;by  Lhe  number  of  bytes  in  a  block 
jContinue  till  all  blocks  are  included 


LDA  1,  UFDSTR+1 1 
ADD  1  ,  0 
STA  0,  SZOFFL 
JMP  AGIJRD 


;Load  the  number  of  bytes  in  the 
;last  block  -  add  to  the  total 
;Storc  total  in  size  of  file 
; Return  to  read  portions  of  QQVV 


ADONCE:  LDA  2,  UFDSTR+1 1 
STA  2,  SZOFFL 
JMI’  AGNRD 


;If  just  one  block,  store  the 
;number  of  bytes  in  size  of  file 
jReturn  to  read  the  portions 


DEFINE  VARIABLES  AND  STORAGE  LOCATIONS 


ONE ELK :  1000 
ZERO:  0 

CUTER :  0 

SAVES :  0 

SAVE2 :  0 

SAVE1  :  0 

SAVED :  0 

SAVEC :  0 

CR :  1  5 


; One  block  is  512  decimal  bytes 

;Countcr  storage  location 
;Storage  location  for  accumulator 
;3,  2,  1,  0,  and  the  carry  bit 


;Carriage  return  is  an  octal  15 


1  57 


SEND  FILE  QQVV  OUT  CHARACTER  BY  CHARACTER 


SEKDIT: 

:  STA  3 , 

,  SAVE 3 

STA  2. 

,  SAVE2 

STA  1 , 

,  SAVE] 

STA  0, 

,  SAVED 

MOVL  0,  0 

STA  0, 

,  SAVEC 

LDA  1, 

WRSSZ 

MOVZR 

1,  1 

STA  1, 

WRSSZ 

REFT: 

LDA  0, 

CTEXTPTR 

LDA  ]  , 

MSK  i 

AMDS  1 

,  0 

SKPEZ 

TTOl 

JMP 

1 

DOAS  0 

,  TTOl 

LDA  0, 

0TEXTPTR 

LDA  1  , 

MSK  2 

AND  1, 

0 

SKPBZ 

TTOl 

JMP 

1 

DOAS  0 

,  TTOl 

LDA  3, 

TF.XTPTR 

INC  3, 

3 

STA  3, 

TEXTPTR 

DSZ  WRSSZ 
JMP  KEPT 


LDA 

1, 

PTRIMIT 

STA 

1, 

TEXTPTR 

LDA 

0, 

SAVEC 

MOVR  0 

,  o 

LDA 

0, 

SAVE0 

LDA 

1. 

SAVE1 

LDA 

2, 

SAVE2 

LDA 

3, 

SAVE3 

JMP 

o, 

3 

;Upon  entering  rout i he,  store 
;accumulators  and  carry  bit 


;Load  number  of  bytes  to  write 
;l)ivide  the  number  by  two,  as  two 
;bytes  will  bo  written  per  iteration 

;Load  pointer  to  text  character 
> Load  mask  to  isolate  left  byte 
; Strip  parity  and  swap 

;If  output  line  not  busy,  output 
;this  isolated  character 


;Load  same  text 

;Load  mask  to  isolate  right  byte 
;Strip  parity 

;Output  this  character  when  output 
;line  not  busy 


;Load  the  pointer  to  the  text 
; Increment  the  pointer 

;llave  the  words  all  been  sent? 

;No  -  return  and  repeat  for  the  next 
;word 

;Yes  -  load  the  pointer  to  beginning  of 
;text  buffer  -  CUTS 

jRestore  accumulators  and  carry 


;Return  to  next  line  from  location 
;in  which  subroutine  called 
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DIC FINE  MASKS 


I'SKl  :  177400 

KSK2 :  000377 


RETURN:  JSR  0  .FRET 
;  DEFINE  CONTENTS  BUFFER 

CRTS:  . BLK  122  ;82  decimal  bytes  of  storage 

FS.=0 

TMP=-167 

.END  GET FI EE 


;Mask  to  isolate  loft  byte 
;llask  to  isolate  right  byte 


END  GETFI1.E .  SR 


oooooooooo 


c - 

c - 

c 

c  ++  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
c  +  + 

C  +  READY RE AD. FR  + 

C  +  ****  CREATED  9  AUGUST  1980;  REV  00  ****+ 

C  +  + 

C  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

c 

c - 

c 

£  k  k  k  k  k  k  k  k  k  k 

c 

C  Program  READYREAD.FR  is  called  by  MONITOR. FR  and  returns  to 

C  MONITOR,  whenever  a  disk  file  needs  to  be  prepared  (i.e., 

C  created)  to  accept  data  from  the  "system."  File  VVQQ  is  created 

C  to  receive  the  data  from  the  "system",  which  will  transpire  on  the 

C  next  execution  of  task  call  SYSIN.SR.  This  latter  action  is 

C  triggered  by  a  repeated  call  to  open  the  file  VVQQ,  which  only 

C  succeeds  after  VVQQ  has  been  created.  The  call  to  READYREAD 

C  is  as  follows: 

CALL  READYREAD  ($602) 

The  $602  is  the  return  line  number  in  MONITOR  that  will  next 
be  executed  upon  return  from  READYREAD. 


kkkkkk' 


k  v. 
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**  READYREAD  receives  an  assigned  dummy  return  variable.  ** 

SUBROUTINE  READYREAD  ( I 5DUMRTN ) 

**  This  call  creates  file  VVQQ,  that  will  be  accepting  data  ** 
from  the  "system."  Data  will  actually  be  entered  only  when 
WQQ  is  opened  by  SYSIN.SR. 

CALL  CFILW  ( "DPOF: DIALOG: VVQQ", 2, IERR1) 

IF  ( IERR1  .NE.  1)  TYPE  "IERR1  IS  ",  IERR1 

**  Return  to  the  statement  number  passed  in  I5DUMRTN.  ** 

RETURN  I5DUMRTN 
END 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


END  READYREAD.FR 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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c 

c 

c 


c 

c 


c 

c 

c 

c 

c 

c- 

c- 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 


c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c- 


+  +  +  4  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 
+  RECEVFITE.FR  + 
+  ****  CREATED  9  AUGUST  1980;  REV  00  ****+ 
+  + 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ■> 


•k'Jc'k'k'irk'k-k-i.-k 


Frogram  RECEVFILE.FR  is  called  by  MONITOR. FK  and  returns  to 
MONITOR,  whenever  a  command  sequence  from  an  action  file 
requires  a  "local"  disk  file  to  be  created  to  receive  data 
transmitted  from  the  "system."  REGEVFILE  uses  the  RDOS  file 
CLI.Cil  to  "send"  action  file  commands  to  the  "local"  system. 
Thus,  the  action  file  command  is  inserted  into  CLI.CM  and  then 
a  program  swap  takes  place  to  execute  that  command.  When 
swapping  taker,  place,  functions  within  tasks  are  disabled 
(such  as  . IDEF).  Therefore,  the  task  SYSIN  is  inactivated 
(killed)  and  reactivated  before  and  after  the  swap  -  program 
EXCLI.SR.  Lastly,  RECEVFII.E  deletes  the  temporary  disk  file 
VVQQ ,  as  it  is  no  longer  needed.  The  call  to  RECEVF1LE  is  as 
follows: 


CALL  RKCKVFILE  ( IACTFILE, MDIM1 , $602) 

IACTFILE  is  on<-  line  from  the  action  file  that  is  to  be 
acted  upon  by  the  "local"  system.  MDIM1  is  the  size  of  the 
one-dimcntional  arrray  IACTFILE,  and  $502  is  the  return  line 
number  in  MONITOR  that  will  be  next  executed  upon  return  from 
RECEVF1LE.  All  parameters  are  passed  from  MONITOR  to  RECEVFILE. 

********** 
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n  o 


c 

C  KKCEVULE  receives  an  input  array,  the  dimension  of  that  ** 

C  array,  and  an  assigned  dummy  return  variable. 

C 

SUBROUTINE  RECEVl’lLE  (  I  NO  ARRAY ,  I6D1MAR ,  16DUMRTN  ) 

C 

C  **  SYS1N.SR  is  the  task  program  that  monitors  "system"  input  ** 

C  and  was  activated  by  MONITOR.  As  it  is  to  be  killed  and  then 

C  reactivated,  DG  FORTRAN  requires  that  it  be  externally  defined. 

C 

EXTERNAL  SYS  IN 

DIMENSION  I N6 ARRAY ( 1 6 D I MAR ) 

C 

C  **  This  call  creates  file  CLI.CM.  If  it  already  exists,  an  ** 

C  error  of  12  is  returned  in  JERRI.  If  the  call  is  okay,  an 

C  error  of  1  is  returned.  Any  other  error  is  printed  out  for 

C  reference.  This  insures  that  CLI.CM  is  available. 

C 

CALL  CFILW  ("CLI.CM", 2, JERRI) 

IF  (JERRI  . NE .  1  .AND.  JERRI  .HE.  12)  TYPE  "JERRI  IS  ",  JERRI 
C 

C  **  This  call  opens  file  CLI.CM  on  channel  25.  State  the  error  ** 
C  condition  if  not  opened  properly. 

C 

CALL  OPEN  (25, "CLT .CM", 2 , JERR2 ,82 ) 

IF  ( JERR2  .NE.  1)  TYPE  "JERR2  IS  ",  JERR2 

**  Insert  command  sequence  from  action  file  into  CLI.CM.  ** 

C 

WRITE  (25,6001)  (IK6ARRAY(L1),  LI  =  3 ,  I6DIMAR) 

6001  FORMAT  (111  ,  80A1 ) 

C 

C  **  Close  CLI.CM  so  it  can  be  deleted  in  EXCLI.SR,  after  it  is  ** 
C  no  longer  needed. 

C 

CALL  CLOSE  (25.JERR3) 

IF  ( JERR3  .NE.  1)  TYPE  "JERR3  IS  ",  JERR3 
C 


oooooonooooo  noo 


C 

C 

C 

C 

C 

C 

C 

C 

C 

C 

c 

c 


c 

c 

c 

c 


**  Before  executing  the  swap  (EXCLI),  inactivate  SYSIN.  ** 

SYSIN  is  the  only  task  with  priority  one  (1). 

CALL  AKILL(l) 

**  EXCLI  swaps  to  level  two  (2)  to  execute  the  instruction  ** 
just  inserted  into  CLI.CM.  Level  two  (2)  is  the  RDOS  CLI. 

Upon  completion  of  the  swapped  program,  control  returns  to  the 
next  instruction  in  this  program. 

CALL  EXCLI 

**  Reactivate  SYSIN  just  as  it  was  before  the  swap.  ** 

CALL  ITASK  (  SYSIN , 10 , 1 ,JERR4, 1 ) 

IF  ( JERR4  .NE.  1)  TYPE  "JERR4  IS  ",  JERR4 

**  Upon  return  from  the  swap,  delete  file  VVQQ,  as  it  is  no  ** 
longer  required. 

CALL  DFILW  ( "DPOF : DIALOG : VVQQ" , JERR5) 

IF  (JERR5  .NE.  1)  TYPE  "JERR5  IS  ",  JERR5 


**  Return  to  the  statement  number  passed  in  I6DUMRTN. 


RETURN  I6DUMRTN 
END 


+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
+  + 


+ 


END  RECEVFILE.FR 


+ 


+  + 
+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  ^  1-  +  +  +  +  +  +  +  +  +  + 
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+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  4  +  +  + 


+  + 

+  TOTERM. SR  + 

+  ****  CREATED  27  JUNE  1980;  REV  02  ****  + 

+  + 


+  +  +  4  +  +  +  +  +  +  +  +  +  +  +  H  +  •*•  H  +  +  +  +  +  +  +  + 


k  «  V'  "kkk  vV  *  *A' 

Program  TOTERM. SR  is  called  from  MONITOR. FR  and  always  calls 
TERMOP. SR  in  turn.  This  program  transitions  the  user  Iron  the 
MONITOR  Command  Language  to  the  transparent  terminal  only  mode. 

The  transition  is  effected  wherever  the  user  enters  "~T"  anywhere 
in  the  command  line  after  MONITOR  provides  its  prompt.  The 
program,  in  addition  to  jumping  to  TERMOP. SR,  also  removes  the 
"system"  device  codes  that  were  identified  (via  .IDEE)  in  SYSIN.SR. 
This  is  necessary,  since  TDRI;01’  identifies  its  own  device  codes. 
Both  TLRNOP  and  SYSIN  use  the  same  device  codes  —  $TT01  and  ?  i"i  II. 
There  are  no  arguments  or  parameters  that  are  passed  via  TOTEUM. 

k'kk'k'kk  k'k'k'k 


•TITL  TOTERM 
.ENT  TOTEi.M 


. EXTD  TERMOP 


. TXTM  1 
.  EXTU 

.  EXTN  .1 


•.Program  name  -  To  Terminal  Operation 

;Enablcs  c  :  ie  entry  into  this 
; program 

;Dec’  .s  program  name  (address) 
;TKRMOP.SR  as  external  displacement 
; TERMOP  can  now  be  accessed  by  TOTERM 

;Packs  ASCII  strings  left  to  right 

;Undefined  variables  are  treated 
;as  External  Displacement  variables 

• ;Provides  some  FORTRAN  initialization 


> 
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;Zero  relocatable  space  starts 


.ER:  l.RR 

.  TOTI-R!! :  TKRMOP 


;Acccss  to  ERR  and  TERMOR  nay  be 
jgained  via  indirect  addressing  to 
; these  locations 


.NREL  ;Norraai  relocatable  space  starts 

FS. 

FIRST  REMOVE  ID!  NT!  FI  ED  DEVICE  CODES 


TOTERli: JSR  0  .FARE 

I.DA  0,  Dl  CODE 
. SYSTM 
.  1 RKV 
JMP  CHKER 


LDA  0,  D2C0DE 
.SYSTM 
.  I RMV 
JMP  CHKER 


JUMP  TO  TF.Rl'OP  .  SR 


JMP  0  .TOTKRM 


;Load  device  code  for  $TTI1 

;  Remove  it  from  the  "svsten" 

; If  an  error,  check  to  see  if 
;dcvice  has  already  been  removed 

;Load  device  code  STTOl 

; Remove  it  from  the  "system" 

;If  an  error,  check  to  see  if 
jdevice  lias  already  been  removed 


ROUTINE  TO  CHECK  FOR  EXPECTED  FUROR 


CHKER  : 

LDA 

1, 

. ERDNM 

;llas  device 

been  removed? 

SUB 

2, 

I  ,  SNR 

JMP 

(" 

. TOTLRM 

;Yes  -  jump 

to  TERMOP 

JMP 

0 

.  ER 

;No  -  state 

the  abnormal  error 

ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERR:  .SYSTM 

.ERTN  ;Abnormal  return  -  error 

JMP  @  .ER 
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VARIABLES  DEFINED 


.ERDNK:  ERDN’M 

D1C0DK:  Till 
D2CODI; :  TTOl 


;ERDN'M  =  36,  device  not  in  system  error 

;$TT01  is  the  first  device  code 
;$TT01  is  the  second  device  code 


JSR  Q  .FRET 


FS.=0 

TMP=-167 


.END  TOTERM 


+  +  +  +  +  +  +  +  +  +  +  H  +  +  +  +  +  +  +  +  +  +  H  +  +  +  + 

h  + 

4  END  TOTERM.SR  + 

+  + 

+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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+  +  +  +  +  +  +  +  +  +  H  +  +  +  +  +■»  +  ■(  +  +  +  +  +  +  +  + 


+  + 

-t  TF.RKOP .  SI!  + 

+  ****  CREATED  30  JUNK  ]  980 ;  REV  02  *••**  + 

+  + 


+  +  +  -^  +  +  +  ^  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 


Program  TERliOP.SR  is  called  by  TOTERV.  .SR,  which  is  called  from 
MONITOR. FR.  TEPdiOl'  is  the  terminal  only  mode  of  operation  for 
inter  conn: uni  cal:  i  on  i  t  h  the  "system."  From  the  "local" 
terminal ,  the  mode  of  operation  in  as  a  transparent  terminal 
connected  to  the  "system."  TER!', OP  serves  as  a  device  driver 
that  enables  intercommunication  between  the  "local" 
system  (devices  $TTO  and  $TTI )  and  a  "system"  connected  to  it 
via  devices  (devices  $TT01  and  $T Til). 


.TITL  TF.RKOP 
.  EXTN  .TASK 

.ENT  TERMOP 

.  TXTM  1 
.  EXTU 


.EXTN  .1 


;Progran  name  -  Terminal  Operation 

;Permits  program  to  externally 
;acc,ess  task  call  TASK 

•.Enables  outside  entry  into  this 
; program 

jPacks  ASCII  strings  left  to  right. 

;Undefinod  varaibles  are  treated  as 
jExternal  Displacement  variables 

■.Provides  some  FORTRAN  initialization 
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;Zero  relocatable  space  starts 


.  Z  KEL 

.Eli:  error 

. KO'j'I  :  NOTE. I 
. NOT 2 :  NoTK 2 


.NULL 


;A cross  Lo  ERROR  am!  NOTEl 
;inay  be  gained  via  indirect 
; addressing  to  these  locations 


; Norma  1  relocatable  space  starts 


DEVICE  CONTROL  TABLE  (»CT)  LAYOUT 


A1 1)CT : 

Till AD 

A2DCT : 

TTOl AD 

TTI1AD: 

ETA ISA 

-1 

T  Till  LA 

TTOl AD: 

STA2SA 

-1 

TTOl RA 

AUDIT IDEAL  VARIABLES  FOR  $TTI1/$TT01 


DICODE: 

TTI 1 

D2C0DE: 

TTOl 

STA1SA: 

.  BLK 

10 

STA2SA: 

.  15  LK 

10 

; Address  of  Till  DOT 
jAddross  of  TT01  DOT 

;  Interrupt  state  save  area  -  TT1 1 
;MasL  word  for  no  interrupts 
;TTI1  interrupt  service  routine 
;  a  d  d  r  c-  s  s 

; Interrupt  state  save  area  -  TTQ1 
;Mask  word 

; TTOl  interrupt  service  routine 
; address 

H  MIDLERS 


;  Dev  ice  code  -  TTI.l 
;Device  code  -•  TTOl 

jEiglit  word  state  save  area  -  Till 
;Same  --  TTOl 
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START  Or  TEKN1  NAL  OPFRATl  OR  PROGRAM 

rs. 

;Lond  dc-fault  mask 
; Load  byte-pointer  to  N0TE1 

;  Write  MOT  El  to  T'J'O 

DEFINE  DEVICES  $TTI  1  /  $TT0l 


TERMOR :  JSR  G  .FARE 


SUR  1 ,  1 
El'A  0,  C.NOT1 
.  SYRTM 
.V.'RL  21 
JMP  G  . ER 


DEE1DEV:LDA  0, 

D1  CODE 

;l)efine  TT1 1  via  the  .IDEE 

LDA  1  , 

A1DCT 

;call,  using  device  code 

. SYSTM 

;TTI1  and  its  DCT  address 

.  IDEE 

JMP  G 

.ER 

DEE2DEV : LDA  0, 

D2CODE 

;Define  TTOi  via  the  .IDEF 

LDA  1  , 

A2DCT 

;call,  using  device  code  TTOl 

.SYSTM 

;and  its  DCT  address 

.IDEE 

JMP  G 

.ER 

DEE1 ME  LINERD  AS  AN  ASYNCHRONOUS  TASK 


DEETA.SK  :  EDA  0,  I  DANDER 
EDA  1 ,  TSKPTR 
.TASK 
JKP  P  .ER 

;  DEVICES  $TT]l/$TTOl  DEFCRE 


;Load  the  ID  and  priori  _y  of 
; task  LIKERD;  lead  task  pointer 
; to  LI NERD 


START1 NG 


NIOC  TTI1 
NIOC  TTOl 
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FUST  TASK  —  READ  AKD  V.'IUTF.  CHARACTERS  I- ROM/ TO  TT1  AM)  'l TO 


TERMED :  .  SYSTM 
.  GC1IAR 
JMP  Q  .  KR 
.  SYSTM 
. PCHAR 
JMP  (■’  .IT’ 

LDA  .1  ,  UPAROW 
SUP,;-  0,  1,  SivR 
JMP  I.VTRMOP 

SKl’hZ  TTOI 
JMP  .-1 
DOAS  0,  TTOI 

JMP  YERMRD 

LVTRMOP :  LDA  0,  t-  .NOT2 
SUR  ] ,  1 
.  SYSTM 
.  V.'RL  21 
JMP  0  .  F.R 

:  ROUTINE  TO  RETURN  TO  THE  CLI  K 


;Cct  character  from  TIT 

;Tut  character  to  TTO 


; Compare  character  to  ; 

;If  a  niaLch,  return  to 
;the  CLI.  Othorvi  se  , 

;oulput.  the  character  to  TTOI 


jRcturn  to  terminal  read/write 


KHALI,  Y 


.SYSTM 

.RTN  ;Normal  return  -  no  error 

JMP  C  . F.R 


DEFINE  ADDITIONAL  VARIABLES  USED  ABOVE 


IDAKDPR : 1 0B7+1 0 

TSKPTR:  EINF.RD 
UPAROL':  .TXT  "<0>~" 


;L1NERD  ID  is  ten  (arbitrary); 
;priority  is  also  ten  (arbitrary) 

; Second  tank  is  LIf.’KRD 

;PCI1AR  and  CCtlAR  zero  out  the  left 
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SECOND  TANK  —  i; J'AF>  AND  WRITE  FROM/TO  $TT1  1  AND  $TTO] 


This  routine  operates  on  a  first-in/first-out  buffer  concept. 

A  single  buffer  is  defined  ( 81! fT)  that  is  133  characters 
Ion}'.  (NOTE:  'I  tie  buffer  is  133  words  lorn;,  but  each  '..’orci 
contains  just  one  character  due  to  the  v. ay  the  reads  and 
writes  pack  ASCII  strings.)  Two  pointers  are  defined  to 
keep  track  of  the  latest  character  entered  (INPTR)  and  the 
latest  character  exited  (OUTPTR)  .  A  third  pointer  (CUKPTR) 
always  reriains  at  the  beginning  of  the  buffer  and  is  used  for 
initialization,  vhc'n  required.  A  fourth  pointer  (HAXl’j.k)  is  used  to 
insure  the  buffer  length  is  not  exceeded  when  enterin';  and 
exitin;;  characters.  Pictorial ly,  this  locks  as  follows: 


BUFFER  "BUFF" 


GUTPTR 

\/ 


+  +  +  H  +++  +  -t 


! 

I 

!  BUFF 


1 

! 

BUFF+1  !  BUFK+2 


+++  I  -i  *■ 

/\ 


+  +  +  +  +  +  -f  +  +  -f  + 


CUKPTR 


MAXPTR 

\/ 

/  +  +  -H+  +  +  +-M ++  +  +  -I  -:+++++  +  +  +  +  +  + 

/  !  !  !  ! 

/  !  !  !  ! 

/  !  BUI  I'+l  3 1  !BU1T>132!:-.U1 1+133  ! 

/  ++C  -1  ++++  +  T  +++H  |  +  +  V'r-}  H-+T+  +  +  +  4-  -f 

/\ 

INPTR 


L1KERD:  I, DA  1,  INPTR 
LDA  2,  OUTPTR 
SUB#  2,  1,  SNR 
JMP  LI NERD 

LDA  0,  0OUTPTR 
. SYSTM 
.  PCIIAR 
JMP  P  .ER 

INC  2,  2 
LDA  3,  MAXPTR 
SUB#  2,  3,  SNR 
JMP  INJT1 
STA  2,  OUTPTR 
JMP  LINERD 

IMIT1:  LDA  2,  CllKI’TR 
JMP  I  NIT] -2 


jCompare  in  and  out  pointers 
; I 1  they  are  the  sane,  there  are 
;no  further  characters  to  print 
;Return  to  the  line  reader 

; Otherwise,  output  to  TTO  the 
;contents  of  BUFF  pointed  to  by 
; OUTPTR 


; Compare  OUTPTR+1  and  .UAXTTR 
; I f  they  are  the  sane,  jump 
;to  routine  to  ro-ini  t  i.alize 
jOUTP’iK  with  the  CilXPYR .  Otlierwise, 
jstore  new  value  of  OUTPTR 
; and  return  to  the  line  reader 

; Re- ini tial ize  OUTPTR  by  storing 
; value  of  CUKPTR  in  OUTPTR 
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ADDITIONAL  l'Ul  NTFR  AND  MASK  VARIABLES  DEFINED 


NOT El : 

.  +  1*2 

jBytcpointer  to  N0TE1  message 

.TXT  "You 

hav  e 

entered  into  the  terminal  only  mode.  Proceed ! <1 5>" 

NOTE 2 : 

.  +  1*2 

.TXT  "You 

have 

returned  to  the  local  CLI  n;ode!<15>" 

OUTPTR: 

BUFF 

jlnitialize  pointers  to 

INPTR : 

BUFF 

•.beginning  of  buffer  BUFF 

CHKPTR : 

BUFF 

PMSK  : 

177 

;Mask  to  strip  parity  bit 

$TT11  INTERRUPT  SERVICE  ROUTINE 


TTI1RA:  STA  3,  USP 

STA  2,  SAVE2 
STA  1,  SAVEl 
STA  0,  SAVEO 
MOVE  0,  0 
STA  0,  SAVCC 

DIAC  0,  TTI1 
EDA  3,  PMSK 
AND  3,  0 
STA  0,  PlNPTR 

LDA  1,  INPTR 
INC  1,  1 
LDA  2,  MAXPTR 
SUB#  1,  2,  SNR 
JMP  CHECK 
STA  1,  INPTR 

RETURN:  LDA  0,  SAVF.C 
MOVR  0,  0 
LDA  0,  SAVEO 
LDA  1 ,  SAVEl 
LDA  2,  SAVE2 
LDA  3,  USP 
JMP  0,  3 

CHECK:  LDA  3,  OUTPTR 
LDA  2,  CHKPTR 
SUB#  2,  3,  SNR 
JMP  PROBl 


STA  2,  INPTR 
JMP  RETURN 

HALT 


;Save  the  previous  processor 
; state  by  saving  all  accumulators 
;and  the  carry  bit.  USP  is  the 
;User  Stack  Pointer,  location 
;016  (octal ) 


Input  the  character  from  TTI1  Lo 
accumulator  zero,  and  strip  the 
the  parity  bit  in  the  right  byte 
Put  character  in  next  empty 
buffer  location 

Is  the  INPTR  at  the  end  of  BUFF? 
Increment  INPTR  to  compare  with 
MAXPTR.  If  they  are  the  same, 
jump  to  check  the  location  of 
OUTPTR.  Otherwise, 
store  the  new  value  of  INPTR 

Restore  the  state  of  the  processor 
before  returning  to  the  next 
instruction  in  the  program 
interrupted  by  input  from  TTI1 
(This  could  be  either  of  the 
two  tasks  of  TERKOP) 


;If  outptr  is  still  at  the 
jbeginning  of  the  buffer  BUFF, 

; there  is  a  buffer  overflow 
;potential  requiring  the  processor 
;to  halt!  Otherwise, 

;store  the  new  value  of  INPTR 
;and  then  return 

;Not  a  recoverable  errror  - 


PROBl : 


STOP! 


$TTOl  INTERRUPT  SERVICE  ROUTINE 


TTOlRA:  NIOC  TTOl  ;Idle  the  device  TTOl  end 

JMP  0,  3  ; return.  No  need  to  save  the 

;the  processor  state,  as  it  is 
;not  changed 

;  ROUTINE  TO  RETURN  TO  THE  CLI  ABNORMALLY 


ERROR:  .  SYSTI1 

. ERTN  ; Abnormal  return  -  error 

JMP  Q  . ER 


DEFINE  NECESSARY  STORAGE  AREAS  TO  BE  USED 


SAVLO :  0 

SAVE1  :  0 

SAVE  2:  0 

SAVEC :  0 

KAXPTR  :  BUFiN  133  . 
BUFF:  .BEK  133. 


; Processor  save  state 
; 1 ocat ions 


jPointer  to  the  end  of  BUFF 
;BUFF  is  133  v/ords  long  (decimal) 


JSR  Q  .FRET 

FS.=0 

TMP“-167 

.END  TERMOP 

>  *“ '  —  —  —  — —  —  —  —  —  — ' 

j  . 

1  :  +  +  +  +  +  +  +  4+  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 

;  +  + 

;  +  END  TERMOP. SR  + 

;  +  + 

:  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  +  + 
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*  ~k  iV  ■>':  V?  *A  -A'  * 

Program  SYSIN. SR  i  s  an  asynchronous  task  that  is  activated  via 
task  calls  and  inactivated  via  task,  cal  Is.  Initially,  SYS  IK  is 
activated  by  NON  3 1  OR. PR.  It  is  subsequently  inactivated  and 
reactivated  by  SUNUP  ILK.  FR  and  RKCi.Vi  1L1  .id.  MONITOR  also 
inactivates  SYS1N  just  l- of  ore  shifting  to  the  terminal  only 
mode  of  operation.  SYSIN  does  several  tilings  s  imul  taneou  1  y  . 
First,  it  defines  device  codes  $TTOl  and  S'i'TIl  that  an-  not 
system  generated.  Second,  SYS  IN  reads  the  input  line  fro::,  the* 
"system"  -  $TTI1  -  after  the  device  defined  interrupt  routines 
store  the  input  in  a  buffer.  Third,  SYSIN  readies  task  MONITOR 
whenever  it  is  suspended.  And  fourth,  SYS  IN  writes  to  file 
VVQQ  whenever  it  is  created  by  program  P.  PC  l:\TIl.h .  SYS  IK  is  of 
priority  1,  which  is  lower  in  precedence  than  MONITOR,  which  is 
of  priority  0.  SYSIN  also  has  the  identity  number  10.  As 
SYSIN  is  not  a  subroutine,  there  are  no  arguments  or  parameters 
that  are  passed  via  SYSIN. 

•k’k'k'k'k'ic'k'kl:  x 


.TITL  SYSIN  jProgrcm  name  -  System  Input 

.ENT  SYSIN  ".Enables  outside  entry  into  this 

; program 

.EXTD  .BUF1,  .BUF2,  .FBI,  .FB2  ;These  storage  locations  were  created 

;by  CNVRT.SR  and  must  be  accessed  by 
;SYSliS.  They  are  external  displacements 

.EXTN  .ARDY  ; .ARDY  roadies  suspended  tasks  and 

;must  be  declared  external  normal 

.TXTM  1  ;Packs  ASCII  strings  left  to  right 

. EXTU  ;Undefined  variables  are  treated  as 

•.External  Displacement  variables 
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ZREL 


{Zero  relocatable  space  starts 


.ER:  ERR 


;ERR  may  be  addressed  indirectly 
;via  this  location 


■i 


3 

•  NREL 

{Normal  relocatable  space  starts 

3 

DEVICE  CONTROL  TABLE 

LAYOUT 

DlDCT 

:  I1AD 

; Address  of  $TTI1  DCT 

D2DCT 

:  OlAD 

{Address  of  $TT01  DCT 

HAD: 

SSA1 

{Interrupt  state  save  area  -  $TTI1 

-1 

{Mask  word  for  no  interrupts 

I1RA 

{ $TTI 1  interrupt  service  routine  addres; 

OlAD: 

SSA2 

{Interrupt  state  save  area  -  STTOl 

-1 

{Mask  word 

OIRA 

;$TT01  interrupt  service  routine  addres 

> 

3 

ADDITIONAL  VARAIBLES 

FOR  $TTI1/$TT01  HANDLERS 

CODEl 

:  TTI1 

{Device  code  -  $TTI1 

C0DE2 

:  TTOl 

{Device  code  -  $TT01 

SSA1 : 

. BLK  10 

{8  decimal  word  state  save  areas 

SSA2 : 

.  BLK  10 

3 

3 

DEFINE  BYTEPOINTER  AND  NULL  WORD 

TMPFL 

:  .+1*2 

{Bytepointer  to  file  VVQQ 

.TXT  "DPOF: DIALOG 

:VVQQ" 

NULL: 

0 

;A  null  word 

3 

3 

DEFINE  THE  DEVICES 

SYSIN 

:  SUB  1,  1 

{This  is  no  operation  -  holds  a  place 

DEVI: 

LDA  0,  CODEl 

{Define  $YTI1  via  the  .IDEF  call. 

LDA  1,  DlDCT 

{using  device  code  $TTI1  and  its 

•SYSTM 

;DCT  address 

.  IDEF 

JMP  @  .ER 

DEV2: 

LDA  0,  CODE2 

{Define  STTOl  via  the  .IDEF  call, 

LDA  1,  D2DCT 

{using  device  code  STTOl  and  its 

.SYSTM 

;DCT  address 

.IDEF 

JMP  @  .ER 

4 
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DEFINE  AN  ASYNCHRONOUS  TASK  TO  READ  LINE  INPUT 


SET: 


RSET1 : 


I,  DA 

1, 

INPTR 

EDA 

2, 

OUTPTR 

SUB? 

2 

,  1  ,  SNR 

JMP 

C11KDLAY 

I. DA 

1, 

DLAYCNT 

STA 

1, 

CNTER 

JUNE 

:  i! 

!PUT 

LDA 

0, 

PCUTFTR 

INC 

2, 

2 

LDA 

3, 

MAXPTR 

SUB* 

:  2, 

,  3,  SNR 

JMP 

RSETl 

STA 

2, 

OUTPTR 

LDA 

3, 

NULL 

SUB?/ 

3 

,  0,  SNR 

JMP 

RDL1NE 

STA 

0, 

CMATPTR 

LDA 

3, 

MATPTR 

STA 

3, 

FMATBUF 

LDA 

1, 

LF 

SUB?/ 

0 

,  1  ,  SNR 

JMP 

cot 

;par 

LDA 

1, 

CR 

SUBI? 

;  0 

,  1  ,  SNR 

JMP 

CO! 

1PAR 

INC 

3, 

3 

STA 

3, 

MATPTR 

JMP 

RDLINE 

LDA 

2, 

CHKPTR 

JMP 

SET 

;Cotupare  in  and  out  pointers.  If 
;they  are  the  same,  there  arc  no  further 
;charactors  from  input 
; Check  a  delay  time-out  before 
^readying  task  MONITOR 

; Otherwise,  insure  time-out  parameters 
;are  reset  and  initialized 


;Load  the  contents  of  outptr 

;Incrcment  the  outpointer  itself 
;Load  the  maxpointer  and  compare  to 
;outpointer.  If  they're  equal, 

;reset  pointer  to  beginning  of  buffer 

^Otherwise,  give  outpointer  a  new  value 

;Load  a  null  word 

;Is  the  character  a  nul 1 ?( Input ) 

;Yes  -  throw  it  away  and  get  next  one 

;No  -  store  character  in  Match  Buffer 
;Save  this  location  in  Full  Match  Buffer 

;Is  character  a  line  feed? 

;Yes  -  compare  all  of  Match  Buffer 

;No  -  Is  character  a  carriage  return? 

;Yes  -  compare  all  of  Match  Buffer 

;No  -  increment  the  match  buffer  pointer 

;Store  the  new  value 

;Return  to  get  next  input  character 

;If  outpointer  is  at  the  end  of 
;its  buffer,  reset  to  the  beginning 
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AFTER  A  DELAY  TIME-OUT,  READY  MON J TOR 


REDYTSK  :  EDA  1,  MAT  ITU 
EDA  2,  MATSTR'l 
SIT,;-  2,  1,  SZR 
JMP  COMPAK 

.  SYS 'I'M 
.CLOSE  27 
JMP  .+1 

EDA  0,  TSKPR1 
.ARDY 

JMP  RDLTNE 

;  DELAY  BLEORF.  READYING  MONITOR 


C11KDLAY :  DSZ  CUTER 
JMP  DLAY 
LDA  1  ,  DLAY CUT 
STA  1  ,  CN'TER 
JMP  REDYTSK 

DLAY :  LDA  .1  ,  PULSC 

. SYSTK 
.DELAY 
JMP  @  .ER 

JMP  RDLIKE 

;  DEFINE  VARIABLES  AND  BUFFERS 


PULSC:  3 

CUTER :  32 

DLAYCNT:32 
TSKPRI:  0 

MATPTR :  KATBUFR 
MATSTRT  rMATBUFR 
FMATP.UF :  0 

RSPSZ :  0 

LF:  12 

CR:  15 

PMSK :  177 


;Insure  nothin-,  is  in  the  mate'll  Duffer 
;If  something  is  there,  compare  the 
; entire  buffer 

;lf  not,  then 
;  close  file  VVQQ 

;If  already  closed,  just  continue 

;Lond  the  priority  of  MONITOR 
; Ready  MONITOR 

;Return  to  get  next  character 


;Decrer.;ent  the  counter  -  if  not  aero 
;delay  a  while  longer 
; Otherwise,  reset  delay  values  and 

;allov  MONITOR  to  take  control 

;Load  the  number  of  pulse  counts 

;Delay  processing  for  the  time  allotted 

; Return  to  check  the  input  again 


;3  decimal  counts  —  3/10  sec 
; Initial  count  is  26  decimal 
;This  creates  a  7-1/2  sec  delay 
;MOUITOR's  task  priority  is  0 

;A  pointer  to  start  of  Match  Buffer 
;  Same 

;Location  of  a  full  Match  Buffer 

;Te\iporary  location  to  store  size  of 
;responscs  gathered  from  CUVRT.SR 
;Line  feed  i s  an  octal  12 
;Carriage  return  is  an  octal  15 
;Mask  to  strip  parity  bit 
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LOOK  AT  THE  MATCH  JWJTT.R  ALT)  COMPARE  TO  EXPECTED  RESPONSES 


COIH’AR :  LDA  0,  MATSTRT 
LDA  1,  .  FJ>1 
LDA  2,  . HU El 

sta  i ,  rbpsz 

CPI’.  1  AG :  STA  0,  MAT PTR 
LDA  0,  t-'KATPTR 
LDA  3,  0,  2 
SUB#  0,  3,  SLR 
JMI’  CMPlll 

LDA  0,  MAT S'i’RT 
LDA  1,  . FB2 
LDA  2,  .r.Ui'2 
STA  1  ,  RSPSZ 

CPR2AG :  STA  0,  MATPTR 
LDA  0,  C; MATPTR 
LDA  3,  0,  2 
SUB i?  0,  3,  SKR 
JMP  CKPR2 

;  OPEL  VVQQ  IF  IT  HAS  BLEU  CREATED 


LDA  0,  TMPFL 
SUB  1,  1 
. SYSTM 
.OPEL  27 
JMP  ERCIIK 
JMP  WJ’TOFL-1 


;Load  start  of  Match  Buffer 
I  Load  size  of  firsL  response  expected 
;Load  starting  location  of  first 
; response  buffet.  Store  size 

'.After  setting  pointer, 

;get  the  character  input 

.Get  first  character  of  response  buffer 

;Are  they  the  same? 

;Yes  -  reset  values  to  check  next  input 

;No  -  start  at  the  buffer  beginning 
;Load  size  of  second  expected  response 
;Load  start  of  second  response  buffer 
‘.Store  size 

;Look  at  characters  just  as  before 


;Load  bytepointer  to  file  VVQQ 
;Load  the  default  mask 

;Open  VVQQ  on  channel  27 
;Chcck  for  expected  error  condition 
;lf  no  error,  then  begin  output  of 
;file  VVQQ  to  "system" 
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output  r::i  xr. cj  ;.i>  rj.si cxsk.s  to  terminal  scrrk:: 


LDA  1 ,  MATSTRT 


OUTI’I’T:  STA  1,  MATPTK 

lda  o,  m; 
.  SYSTM 
.  PChAR 

jmp  i  .  l  r 

I. DA  2,  FM."FUF 
S  I’B- '  1,  2,  SLR 
JMP  TORDLIK 


I  AC  1  ,  1 
J Ml’  OUTPUT 

Di;r i  ;;k  buffer  pointers  to  buffers 


OUTPTR :  DU PR 
CHKI’TR :  BUJ'II 
IKPTR:  BUFR 

MAXPTK :  DUFR+133 


;If  VVQQ  does  not  exist,  output 
;Katch  Buffer  contents  to  terminal 

;Start  at  beginning  of  Match  Buffer 

; Put  a  character  to  terminal  -  $TTO 

; Load  location  of  last  buffer  character 
;ls  output  complete? 

;Yes  -  send  carriage  return  and  read 
;the  next  line  for  input 

;No  -  increment  buffer  pointer  and 
;  repeat 


;Pointer  to  next  output  character 
•.Pointer  to  buffer  start 
; Pointer  to  next  input  buffer  locution 
jPointer  to  the  end  of  input  buffer 


OUTPUT  CARRIAGE  RETURN  AS  LAST  CHARACTER  OF  A  WRITE 


TOP.DLIK  :1.  DA  0,  CR 
. SYSTM 
.  PCilAR 


JMP 

C 

.KR 

LDA 

1  , 

MATS  TP. 

STA 

1, 

IIATPTK 

JMP 

KDLIKE 

;Load  carraige  return 

;Put  carraige  return  to  terminal 

;Reset  pointers  to  beginning  of  Match 
;Buffer  and  return  to  read  the 
;next  1 inc 


1' 
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CONTINUE  TO  COMPARE  EXPECTED  RESPONSES  WITH  It; PUT 


LDA 

0,  MATl'iR 

;Look 

at  next  character  in 

INC 

0,  0 

;responsi  buffer  and  match  buifer 

IKC 

2,  2 

DSZ 

ksfsz 

;Hcs 

the  size  of  the  expected  response 

JMP 

CPE  1 AG 

;boen 

exceeded?  No  -  continue  comparing 

LDA 

] ,  MATSTRT 

;  Y  e  s 

-  reset  buffer  pointers 

STA 

1 ,  MATPTR 

;  and 

return  to  read  the  next  1  ine 

JMP 

RDLINE 

LDA 

0,  MATPTR 

;Do  the  same  for  second  response 

IKC 

o 

o 

INC 

2,  2 

DSZ 

RSPSZ 

JMP 

C  Pi!  2  AG 

EDA 

1,  MATSTRT 

STA 

1 ,  MATPTR 

JMP 

RDLINE 

CHECK  FOR  AN  EXPECTED  ERROR  CONDITION 


KECIIK:  I, DA  1,  .ERDEE 
SUlIi;  ],  2,  SHR 
JMP  OUTPUT- 1 
EDA  1,  .KRUFT 
SUP.-  1,  2,  SZR 
JMP  P  .EK 


;I.oad  expected  error  code  -  ERDLi; 

;Does  file  VVQQ  exist? 

;No  -  jump  to  output  to  terminal 
;Load  another  expected  error 
;Is  tliis  channel  in  use? 

;No  -  state  unexpected  error  condition 


IF  FILE  VVQQ  EXISTS,  WRITE  ALL  INPUT  TO  IT 


EDA  1 ,  KATSTRT 
V.’HTOFL :  STA  1,  I1ATPTR 
LDA  1 ,  ONE 
EDA  0,  MATPTR 
MOVOL  0,  0 
. SYSTM 
. WUR  27 
JMP  P  .ER 


;Yes  -  write  input  buffer  toVVQO 

;Load  one  (1)  -  number  of  bytes  to  write 

;Eoad  pointer  to  natch  buffer 

;Make  this  a  bytepointer  to  right  byte 

;Write  right  byte  to  VVQQ 


LDA  ] ,  MATPTR 
LDA  2,  FMATKUSH 
SUIi#  1,2,  SNR 
JMP  TORDLINE 
IKC  1  ,  1 
JMP  WRTOFL 


jl.ook  at  pointer  to  ntclch  buffer 
;and  location  of  last  character 
;Is  buffer  writing  comlete? 

;Yes  -  return  t.o  read  next  line 
;No  -  incremeni  pointer  and 
;write  next  character  to  VVQQ 
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DEFINE  VARA  I  i’.I.KS 


.  EKUFT :  nil!  FT 
.  FRDLE :  FEDLK 
ONE:  1 

;  $TT0.1  INTERRUPT  SERVICE  KOUTJUK 


Cl  FA:  NIOC  TTOl 

JMP  0,  3 


$TTI1  INTERRUPT  SKRVICi:  ROUTINE 


I 1 KA :  STA  3,  USP 

STA  2,  PAVE2 

STA  1,  SAVF1 

STA  0,  SAVED 

MOVE  0,  0 
STA  0,  SAVEC 

DIAC  0,  Till 
LDA  3 ,  PMSK 

AND  3,  0 

STA  0,  CJ  IKPTR 

LDA  1,  IKPTR 

1KC  1,  1 

LDA  2,  MAXPTR 

SI. Ail'  1,2,  SNR 
J I  IP  CIIEK 
STA  1,  IKPTR 

RETRN :  LDA  0,  SAVEC 
KOVK  0,  0 
LDA  0,  SAVED 

LDA  1 ,  SAVL1 

LDA  2,  SAVK2 

LDA  3,  USP 

JMP  0,  3 

CHEK :  LDA  3,  OUTPTR 

LDA  2,  CIIKPTR 

SUB#  2,  3,  SNR 
JM1>  PRO  15 1 

STA  2,  IKPTR 
JMP  RETRN 

PKOB] :  HALT 
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;l!U  i  i  -  21  ,  channel  in  use 
;ERDLE  =•  12,  file'  tie,,  r.  not  i t 


;  Idle  device  $TTOl  and  return  to  next 
;  1  inc  after  interrupt.  No  need  to  tav 
1  the  processor  state,  as  it  is  not 
; changed 


Save  the  previous  processor  state  by 
savinp,  all  a  ecu;. Inters  and  the  carry 
bit.  USP  is  User  Stack  Pointer 


;Input  character  fro.-.  $ T T J .  1 
;Strip  parity  1>  i  t:  and 

;  store  in  BUFIt 

; Load  pointer  to  next  BULK  location 
; Increment  it 

;Loed  pointer  to  last  buffer  entry 
;Is  buffer  full?  Yes  -- 
;jurnp  to  see  if  buffer  has  been  used 
;No  -  store  new  pointer  value 

; Restore  the  state  of  the  processor 


; Return  to  next  location  after  intorru 

;lf  outptr  is  still  a:  t  ho  be;  inniny 
;of  the  buffer  Bl’Fil,  there  is  a 
;buffer  overflow  potential  rn;uiri  np 
;tbe  processor  to  ha  1 1  .  Otherwise, 

;  store  new  value  of  IN'P" R  and 

; return 

; Not  a  recoverable  error  -  STt ” 1 


KOI'Y  INK  TO  KfTPKi;  TO  *j  i ! K  CU  A1’.::0!:''M,LV 


I'.KK:  .SYSTi; 

.  ERTII  ;Abrioroa  1  return  —  error 

JHP  Q  .IK 

;  DF.KIKi:  STOKAOF  ARF.AS  AND  CUFFFKS 


SAVi.O:  0 
SAVl'l  :  0 

SAVK2 :  0 

SAY FC :  0 

MATBUFR : ,  BJ.K  133.  ;)iatch  buffer  has  91  decimal 

I!DFR:  .  DLK  133.  ;  loacat  i  oni. .  So  does  input  buff 


.  FNlJ  SYS  IN 


^Storape  area  for  arcumul a  tor  0, 
;1,  2,  and  carry  bit 
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AIR  FORCE  INST  OF  TECH  MRIOhT-RATTERSON  AF0  OH  SCMOO— £TC 
CONSTRUCTION  OF  A  GENERAL  PURPOSE  COMMA NO  LANOUA6E  FOR  USE 
SEP  60  N  D  OR  I ESS 
AFIT/GCS/EE/60S-1S 


F/6  9/2 
IN  C— ETCf- 

NL 


DTIC 


c - 

c - 

c 

C  THIS  IS  THE  CYBER  ACTION  FILE. 

C  +++++++  CREATED  7  AUGUST  1980;  REV  01  ++ 

C 

C  THE  FIRST  CONTROL  CARD  IMAGE  (i)  CONTAINS  EXPECTED  RESPONSES  FROM 
C  THE  CYBER  SYSTM. 

I  COMMAND-,.. 

C 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  SENT  TO  THE  SYSTEM. 

C  CORRECT  INPUT  IS:  PUT,LFN,SFN,ID,SFPASSWRD 

. CACT , PUT , #1 , #2 , #3 , #4 

v;s  COPYBF,  INPUT, ZQY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, ZQY 

WS  REQUEST , ZQZ , *PF 

WS  COPYBF, ZQY.ZQZ 

WS  CATALOG , ZQZ , #2 , ID=#3 , RP=999 , PW=i?4 

WS  RETURN, ZQZ, ZQY 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  RECEIVED  LOCALLY. 

C  CORRECT  INPUT  IS:  GET , SFN , ID, SFPASSWRD , LFN 

. CACT, GET, #1, #2, #3, #4 
WS  ATTACH , QZQ , #1 , ID=#2 , PW=#3 

RR 

WS  COPYSBF, QZQ, OUTPUT 

RC  XFER/A  VVQQ  # 4/R 

WS  RETURN, QZQ 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  PRINTED  ON  SYSTEM  PRINTER. 

C  CORRECT  INPUT  IS:  SPRINT, SFN, SFPASSWRD 

. CACT , SPR INT , #1 , #2 

WS  ATTACH ,  ZXQ ,  #  1 ,  PW=i?  2 

WS  REQUEST, ZYQ,*Q 

WS  COPYSBF, ZXQ, ZYQ 

WS  REWIND, ZYQ 

WS  ROUTE , ZYQ, DC=PR, TID=BB , FID=NEO , ST=CSB 

WS  RETURN, ZXQ, ZYQ 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  PUNCHED  ON  SYSTEM  PUNCH. 

C  CORRECT  INPUT  IS:  SPUNCH, SFN, SFPASSWRD 

. CACT , SPUNCH , #1 , #2 

WS  REQUEST, ZJQ,*Q 

WS  ATTACH, ZJJ,#1 ,FW=#2 

WS  COPYSBF, ZJJ.ZJQ 

WS  REWIND, ZJQ 

WS  ROUTE , ZJQ ,  DC=PU ,  FID-NEO ,  TID-BB ,  ST*=CSB 

WS  RETURN, ZJQ.ZJJ 

END. 
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C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  DELETED. 

C  CORRECT  INPUT  IS:  DELETE, SFN, SFPASSWRD 

. CACT , DELETE , v 1 , #2 

WS  PURGE  ,UZU  ,i'l  ,PW=#2 

WS  RETURN, UZU 

END. 

C  THIS  COMMAND  PERMITS  DISPLAY  OF  SYSTEM  FILES  IN  USE  ( CREATED, ATTACHED ) . 

C  CORRECT  INPUT  IS:  FILES 

.CACT, FILES 

WS  FILES 

END. 

C  THIS  COMMAND  PERMITS  DISPLAY  OF  SYSTEM  PERMANENT  FILES  (AUDIT). 

C  CORRECT  INPUT  IS:  PFILES.USER  ID  (PROB  NUM) 

.CACT.PFILES ,#1 

WS  AUDIT, AI=P,ID=#1 

END. 

C  THIS  COMMAND  PERMITS  USER  ACCESS  TO  THE  SYSTEM. 

C  CORRECT  INPUT  IS:  LOGON, USER  ID  (PROB  NUM), USER  PASSWRD 

. CACT, LOGON, #1, #2 

WL  Dial  the  CDC  CYBER  telephone  number  (currently  5180  or  5159), 

WL  wait  for  the  tone,  and  then  place  the  telephone  headset 

WL  into  the  modem  receiver.  Now  strike  any  key 

WL  on  the  keyboard. 

RW 

WS  LOGIN, $1, 42, 111 

END. 

C  THIS  COMMAND  TERMINATES  ACCESS  TO  THE  SYSTEM. 

C  CORRECT  INPUT  IS:  LOGOFF 

.CACT, LOGOFF 
WS  LOGOUT 

WL  The  CDC  CYBER  is  logged  out.  Enter  uparrow  L,  "~L",  to  return 

WL  to  the  local  NOVA/ECLIPSE  CLI. 

END. 
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C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  PRINTED  ON  SYSTEM  PRINTER. 

C  CORRECT  INPUT  IS:  LPRINT.LFN 

. CACT , LPR I NT , # 1 

WS  REQUEST, XZX,*Q 

WS  COPYBF, INPUT, XZY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, XZY 

WS  COPYSBF , XZY , XZX 

WS  REWIND, XZX 

WS  ROUTE , XZX , DC=PR , FID=NEO , TID=BB , ST=CSB 

WS  RETURN, XZX, XZY 

END. 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  PUNCHED  ON  SYSTEM  PUNCH. 

C  CORRECT  INPUT  IS:  LPUNCH ,LFN 

. CACT , LPUNCH , #1 
WS  REQUEST, JZX,*Q 

WS  COPYBF, INPUT, JZY 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, JZY 

WS  COPYBF, JZY, JZX 

WS  REWIND, JZX 

WS  ROUTE , JZX, DC=PU , FID=NE0 , TID=BB , ST=CSB 

WS  RETURN, JZX, JZY 

END. 

C  THIS  COMMAND  PERMITS  SYSTEM  FILES  TO  BE  EXECUTED  (BATCHED)  ON  SYSTEM. 

C  CORRECT  INPUT  IS:  SBATCH,SFN,SFPASSWRD, DISPOSITION, TERMINAL  ID 

.  CACT ,  S BATCH ,  #1 ,  #2 ,  #3  ,  #4 

WS  ATTACH , VQY , #1 , PW=#2 

WS  BATCH , VQY , #3 , Y=#4 

WS  RETURN, VQY 

END. 

C  THIS  COMMAND  PERMITS  LOCAL  FILES  TO  BE  EXECUTED  (BATCHED)  ON  SYSTEM. 

C  CORRECT  INPUT  IS:  LBATCH.LFN, DISPOSITION, TERMINAL  ID 

. CACT , LBATCH , #1 , #2 , #3 

WS  COPYBF, INPUT, VQX 

WC  XFER/A  #1  QQVV/R 

WS  %EOF 

WS  REWIND, VQX 

WS  BATCH , VQX , #2 , Y=#3 

WS  RETURN, VQX 

END. 

FINISH. 
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c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 

c 


THIS  ACTION  FILE  MAY  BE  EXPANDED  OR  CONTRACTED,  PROVIDED  ENTRIES  MEET 
THE  FOLLOWING  FORMAT  AND  CONTENT  GUIDELINES: 

A.  COMMAND  IDENTIFICATION  LINES  ARE  PRECEDED  BY  ".CACT"  . 

B.  THE  LAST  LINE  IN  EACH  DISTINCT  COMMAND  SEQUENCE  MUST  BE  "END."  . 

C.  THE  LAST  LINE  OF  THE  ENTIRE  FILE  MUST  BE  "FINISH.",  WITH  THE 
EXCEPTION  OF  COMMENT  LINES. 

D.  COMMENT  LINES  MAY  BE  PRECEDED  BY  ANY  CHARACTER  NOT  RESERVED 
AS  INDICATED  ABOVE  OR  BELOW.  FOR  CONVENIENCE,  "C"  HAS  BEEN 
CHOSEN. 

E.  THE  FIRST  TWO  COLUMNS  OF  EACH  LINE  SATISFY  CONTROL  FUNCTIONS: 

1)  "I  "  PRECEDES  THE  EXPECTED  RESPONSES  FROM  THE  SYSTEM. 

THEY  ARE  USED  TO  INITIALIZE  THE  EXPECTED  RESPONSE  ARRAYS. 

2)  "WS"  PRECEDES  INFORMATION  TO  BE  WRITTEN  TO  THE  SYSTEM. 

3)  "WL"  PRECEDES  INFORMATION  TO  BE  WRITTEN  TO  THE  LOCAL  TERM. 

4)  "RW"  PRECEDES  BLANK  LINE;  INDICATES  A  BACK-TO-BACK  LOCAL 
TERM  READ  FOLLOWED  BY  A  SYSTEM  WRITE. 

5)  "WC"  PRECEDES  CALL  TO  COPY  A  LOCAL  FILE  AND  WRITE  IT 
TO  THE  SYSTEM. 

6)  "RC"  PRECEDES  CALL  TO  COPY  A  LOCAL  FILE  THAT  HAS  BEEN 
READ  FROM  THE  SYSTEM. 

7)  "RR"  PRECEDES  BLANK  LINE;  INDICATES  THAT  AN  "RC"  CONTROL 
WILL  FOLLOW  AND  MAKES  READY  A  LOCAL  FILE  FOR  THE  READ. 

8)  SEE  A  THROUGH  D  ABOVE  FOR  OTHER  CONTROL  FUNCTIONS. 

F.  ALL  LINES  (CONTROL  CHARACTERS)  MUST  BEGIN  IN  COLUMN  ONE  (1); 

ALL  INFORMATION  IN  LINES  OTHER  THAN  THOSE  DESCRIBED  IN  A  THROUGH  D 
ABOVE  MUST  CONTINUE  IN  OR  AFTER  COLUMN  NINE  (9),  EXCEPT  FOR  COMMENT 
LINES.  (TABS  CANNOT  BE  USED  ANYWHERE  IN  THE  ACTION  FILE,  EXCEPT 
IN  COMMENT  LINES  AFTER  THEIR  CONTROL  CHARACTERS.) 
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non 


C  THIS  IS  THE  DEC  ACTION  FILE.  THERE  ARE  NO  ENTRIES 

C  AS  OF  15  JULY  1980. 

C 

I 

FINISH. 


C  THIS  IS  THE  VAX  ACTION  FILE.  THERE  ARE  NO  ENTRIES 

C  AS  OF  15  JULY  1980. 

C 

I 

FINISH. 


THIS  IS  MY  OWN  ACTION  FILE.  THERE  ARE  NO  ENTRIES 
AS  OF  15  JULY  1980. 


I 

FINISH. 
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